On 29.06.23 07:52, Paul King wrote:
Hi Jochen, Thanks for raising that issue. It has been a limitation for some folks for quite a while. I am very keen to improve our joint compilation process if we can.
I was actually wondering if someone really still cares.
I did try one experiment to improve the V0 process by making transforms smarter and idempotent. Essentially, I was trying to get more transform results into the stubs and I was duplicating more of the process. I was basically regenerating stubs after each phase and repeating earlier Groovy phases for files affected by any changes. I was trying to make more things incremental otherwise that approach doesn't scale at all. But I ran out of cycles to explore before getting anything that I would call usable.
interesting... but doesn't that mean you compile the Java part multiple times too? That would be very very bad for performance.
I would be interested in looking at earlier attempts like V2 to see if advances in the meantime now make them more feasible.
[...] V2 was:
V2: Collect class data from javac using annotation processing and feed that to groovyc. This would then be a 3 stage process. First we use javac to get the class information, but javac cannot complete compilation, since not all classes are resolved. Then we use the extracted information to compile Groovy. And finally we compile normally with Java.
The big problem part is that we are working on something that possibly cannot compile in Java. I am actually not sure annotation processors are fully defined in these environments. Needs to be tested. V1 with javaparser has also the option to use the SymbolResolver (which I have not used yet) to resolve classes against imports. In the end it does not matter who is feeding us with the classes from Java. What we need are ClassNodes (non-primary) to give them to the ClassNodeResolver and we are good to go. bye Jochen
