The other "interim" fix would be to try to have more AST xforms run before stub generation. This would not be about trying to do stub generation later but running (some) xforms during a first phase and then rolling back phases and proceeding normally. This isn't a general solution but could cover some more cases. We would perhaps mark xforms with a marker interface if they were amenable to such processing, e.g. if they are idempotent by nature or can be made so by storing some state in node metadata to indicate they have already been run. We also need to look at which bits of the current compiler could be run during that first phase and then pick xforms that are compatible with this (potentially) limited processing. We'd obviously not want to make the compiler significantly slower nor break existing xforms, nor make IDE support significantly harder, so I imagine there would be just some specific cases that we would try to support and numerous limitations.
On Sun, Mar 31, 2019 at 12:43 AM Jochen Theodorou <blackd...@gmx.org> wrote: > On 28.03.19 19:05, Milles, Eric (TR Tech, Content & Ops) wrote: > > This subject has been discussed a few times in the past and I'd like to > > give it a bump. As I mentioned in one of the bugs linked to > > https://issues.apache.org/jira/browse/GROOVY-3683, joint compilation is > > our main use case for Groovy. We have large Java projects and want to > > introduce Groovy little-by-little. We don't want to mess with separate > > source folders and separate compilation. This is generally possible, but > > in terms of AST transforms, we need to be very selective. Introducing > > any new interfaces or methods via AST xforms is a likely source of joint > > compilation errors. > > > > > > Some of the bugs mention efforts to replace stub generation with > > stub-less joint compilation. Did any such exploration take place? Were > > there any fruitful discoveries or experiments? > > Current state in master afaik: > Stubs are created in memory, java compiler compiles from the memory stub > files. The xforms problem is not solved by that though. > > My plans originally: > > I did some experiments in the past involving Javaparser to parse Java > code and present that as class nodes to the Groovy compiler. Compilation > would then happen in two phases: > > Phase 1: parse Java and compile Groovy > Phase 2: compile Java from source leveraging the compiler Groovy sources > > The advantage is that this does not even have to be in the same process, > allowing a build tool to completely unload the Groovy compiler before > starting the Java compiler. Obviously this would solve the problem. IT > would not solve a problem in which for example an annotation processor > for Java is supposed to create missing source/class files during > compilation. This scenario would also cause trouble in the stub version. > > I got as far being able to compile simple scenarios. Till I noticed a > fundamental mistake, that requires me to rewrite everything, which is > where I stopped because of time problems. I don't even remember what it > was exactly, just that I think it was solvable and not a 100% blocker. > > The there is the legacy plan: > > Merge Java and Groovy compiler by building some kind of double > AST-Bridge. This is a failed experiment, because the Java compiler > changes too much for this and you need to deep-dive into the internals a > lot. > > > > The specific case I ran into this week is a class that implements the > > List interface and all method implementations are provided through > > @Delegate. > > > > > > class Foo implements Bar, List<Baz> { > > > > @Delegate private List<Baz> list > > > > } > > > > > > When this is joint compiled, the stub has compilation errors: > > > > [compile] > > org.codehaus.groovy.control.MultipleCompilationErrorsException: > > startup failed: > > > > [compile] Compile error during compilation with javac. > > > > [compile] > > > > C:\Users\...\Local\Temp\groovy-generated-4358726042782385987-java-source\...Foo.java:10: > > error: Foo is not abstract and does not override abstract method > > subList(int,int) in List > > > > > > I didn't realize the stubs were actually compiled. I thought they were > > just referenced by javac to understand the types. > > > > > > *Is there any hope here for generating better stubs, telling javac not > > to compile the stubs or to ignore errors, or something else? I had all > > this working in the IDE and was ready to commit when I ran into the > > brick wall of groovyc/javac handling of Groovy AST transformations > again.* > > There is a scenario allowing javac two compile of source files without > compiling them as well? ... and allows incorrect (parses, but does not > compile) source files? > > It could maybe get better if we would not create source stubs, but class > file stubs... though there is no guarantee the above case would work. > Would need to be tested. > > bye Jochen > > > >
