On 23.02.2016 09:26, Cédric Champeau wrote:
Hi Jochen,
I need more context too. What changes are you talking about? It seems
very abstract so far. I would be in favor of a joint compiler without
stubs in Groovy core itself. I think both Gradle and Jetbrains would be
interested in such a compiler too. And not talking about an incremental
compiler. What, technically, are the necessary changes?
To be frank it just occurred to me that this is actually not a joint
compiler in the sense, that it compiles Groovy and Java at the same
time. Instead I am using a Java parser (Github project javaparser) to
parse Java, produce a Groovy AST from it (including some semantic
information like resolved classes) and then compile our Groovy classes
against this. An actual Java compiler could be in a completely separate
process.
Further plans include producing a javax.model shadow/facade AST, that
allows annotation processors to run on Groovy code (of course without
changing the class), a javadoc style tool with doclet support which can
handle Groovy and Java at the same time and maybe actual joint
compilation with other compilers through javax.model, some kind of IR or
something entirely different I have not thought of yet.
In other words, this little project works quite different from the old
approach of producing stubs from Groovy, run java on the stubs, run
Groovy on the produced classes. Stubs would become an optional extra. We
can probably fiddle most of the current logic into the new one in terms
of ant tasks, and maybe maven2. For Gradle we would have to take a good
look at the groovy plugin before I can tell what needs to change. And
Jetbrains is an entirely different topic...
bye Jochen
