groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <>
Subject Re: AST Transformations and joint compilation
Date Sat, 30 Mar 2019 14:34:00 GMT
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
>, 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

> 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\
>     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

View raw message