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?
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.
