groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <>
Subject Re: a new joint compiler
Date Tue, 23 Feb 2016 11:48:17 GMT
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 

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

View raw message