groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Milles, Eric (TR Tech, Content & Ops)" <>
Subject AST Transformations and joint compilation
Date Thu, 28 Mar 2019 18:05:56 GMT
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?

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

View raw message