Guys, sorry for brevity, in a hurry now.
If you are considering a real support, note please that the name-based detection of generated classes won't work without parsing the source due to the darned packages: unless you parse the source, you can't know in which target sub-folder the generated .class-es will be put to. All the best, OC > On 18. 1. 2024, at 23:18, MG <mg...@arscreat.com> wrote: > > Hi Jochen, > For our case we would not need to have obsolete class files to be deleted, > just that no (typically closure) class files be generated with a different > name, even though they are identical to existing ones. > IntelliJ also does not (at least reliably) remove unused classes even when > doing a rebuild all, we always wipe the out dir completely for that reason > from time to time... > ...rsyncing the result to the server then removes unused classes there too. > But since this does not influence turnaround times, it does not bother us. > From what Jochen says, avoinding regenerating classes needlessly with a > different name seems at least in theory possible through some sort of hashing > mechanism. > From the top of my head: An alternative might maybe be to not number the > closure classes, but to use the the hash value as part of their name, so that > unchanged classes automatically keep the same name. > This would make the names less readable, but more deterministic, but would > require collision avoidance if two hashes collide... > ...but might also allow for closure class sharing (maybe useful for small > collect/forEach closures ?). > Cheers, > mg > > > On 16/01/2024 12:42, Jochen Theodorou wrote: >> >> >> Am 15.01.24 um 20:24 schrieb o...@ocs.cz <mailto:o...@ocs.cz>: >>> Jochen, >>> >>>> On 15. 1. 2024, at 10:35, Jochen Theodorou <blackd...@gmx.org> >>>> <mailto:blackd...@gmx.org> wrote: >>>> If the goal is to give Groovyc a source file and let it compile that, >>>> but write only certain files... well that is something that could be >>>> worked out. >>> >>> Well I don't know. >>> >>> Theoretically, it would be nice if the compiler wrote only those .classes, >>> which did change from the previous compilation. >>> >>> I might be overlooking something of importance, but I fear that would be >>> pretty difficult, at the verge of impossible. I guess the solution might be >>> found somewhere nearby creating some hash of the last generated code, >>> stored in .class, checking when building and not re-writing the .class if >>> unchanged... am not sure whether feasible at all. >> >> Assume the following Java-like >> >> import static Foo.bar >> >> class BarExec { >> public Runable getExec() { >> return new Runable() { >> public void run(){ bar() } >> }}}} >> >> So basically this wraps a call around Foo.bar, in way you would not do >> it anymore these days, but this is just for illustration. So assume my >> change now is replacing the import and import Foo.bar2 instead of >> Foo.bar. Because the method is called in the anonymous class in getExec >> the minimum we need to do is recompile BarExec$1. BarExec does not need >> recompilation, even though the code we changed is not even directly in >> the inner class. That kind of problem makes it really difficult to do >> any kind of partial compilation >> >> But the idea with a hash (where we compile the whole file) sounds >> possible to me. >> >>>> This is not really incremental compilation like we may know >>>> it from eclipse-java though. >>> >>> I've tried to use the Eclipse thing and it was terrible enough (not just >>> due to unreliable incremental build; a plethora of other problems, GUI ugly >>> as hell, contra-intuitive and completely non-ergonomic, slow and crashing >>> pretty often) that I spent a non-trivial time writing my own scripts and >>> even an external EOF model editor to be able to use Xcode to build my >>> WebObjects/Groovy applications :) >> >> yeah, Eclipse has its weaknesses >> >>> Anyway I would be contented with a build system which >>> - never tries to re-compile sources which did not change after the previous >>> build (this works with my scripts all right) >>> - reliably re-builds all the classes generated by a source changed after >>> the previous build (this works with my scripts all right) >>> - reliably deletes classes which were created by the previous build, but do >>> not exist anymore with the current one (and this, alas, my scripts do not >>> support properly yet). >> >> to know what files we would create we would have to do a complete >> compilation process except the actual writing of files. Under the >> assumption of a class Foo will produce a number of class files >> Foo($.+)*.class we could then in theory identify which files for Foo are >> then surplus. But if you for example deleted Bar.groovy, then we do not >> have a Bar.groovy to find out that we do not need Bar.class and >> Bar$1.class anymore. For this we would have to compile all source files, >> though we would not have to create the class files of course. >> >> Now what do you understand under re-compile? process the source like in >> a normal compilation and write out the result, or does it not matter if >> the result is written out? If the later does not matter, then >> determining the list of unused top-level classes conflicts with the idea >> of re-compiling only files that did not change. This is also because in >> Groovy a source file can contain any number of top level classes, it >> does not even have to contain a class that is similar to the name of the >> file. >> >> But of course if you say you want the fixed relationship of one file >> containing one class and its inner classes, then this is actually >> solvable. For example if there is a bar.class but not bar.groovy we can >> delete bar.class. Or if there is bar.class bar$1.class and bar$2.class >> and if bar was changed, then any bar class file with a time from before >> the last compilation can be deleted. >> >>> I understand Eclipse and other Java-related IDEs do this completely wrong, >>> for they naïvely assume an XXX.source always generates just XXX.class. I >>> might be wrong of course — for years I happily use Xcode plus my scripts >>> and haven't touched those other IDEs by a ten-foot pole; perhaps they >>> improved meantime :) >> >> IDEs usually know that there can be more. At least inner classes for the >> Java case. Well... they all got even more memory hungry mostly. >> Sometimes it is interesting to work with something like vscode for >> example. It makes a more lean impression... but in the end it is similar >> bad in terms of memory consumption once you start adding plugins. If you >> are happy with xcode, stay with xcode ;) >> >> bye Jochen >> >> bye Jochen >
