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
