groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <blackd...@gmx.org>
Subject Re: Groovy and Java 9
Date Wed, 25 May 2016 06:12:52 GMT
On 25.05.2016 03:28, Duncan Dickinson wrote:
> Hi all,
>
> I was wondering if there was a summary available regarding the work
> being done around Groovy and Java 9? There was a fair bit of discussion
> around this in late-2015 and concerns raised around Jigsaw. There was
> also a discussion around formulating a minimal roadmap for development.
>
> I'm just wondering where the dev team's thoughts are since the last
> round of discussions a few months ago.

I started creating some JDK9 labeled issues
https://issues.apache.org/jira/issues/?jql=project%20%3D%20GROOVY%20AND%20resolution%20%3D%20Unresolved%20AND%20labels%20%3D%20JDK9%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC

Not much, but better than nothing.

Those issues are the result of me trying to get the Groovy and its test 
running on JDK9. There basically the following things are broken for 
Groovy as jar on JDK9 to properly build:
(1) assuming the app loader is an url loader
(2) joint compilation - often related to (1), since we use the urls from 
there to init the joint compiler. But also the API usage,which basically 
depends on the sun classes. This adds a requirement for adding the 
option "-XaddExports:jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED" 
to the compiler to work. Better would be to replace the current usage 
with the compiler API that is provided since Java6.
(3) grape with system loader. Again this is related to (1). I don´t see 
a solution for this at all
(4) handling of default methods. The old way we did create proxies for 
functional interfaces is not working anymore. So we need a new way and 
have to think about how to support something like ({a,b -> a<=>b} as 
Comperator).reverse(). I don´t have a solution for this. We can drive 
our own proxy generator, but we will most likely get into problems with 
modules later with this.

After those things Groovy would potentially build on JDK9. But this 
build and its test would use zero modules, and Groovy itself would not 
be a module too. I know we will have to add read edges all over the 
place to enable modules work together with Groovy. But in the end it 
depends on actually trying. So the minimal list for Groovy as module 
would be (additionally to the list above):
(5) investigate how and where to add read edges
(6) if multiple modules are used (basically if not groovy-all is used), 
change the modules to not use the same package names, since same 
(exported) packages by different modules is forbidden in jigsaw
(7) have the build system actually create and test with a module
(8) a multitude of things that will pop up after we started making 
Groovy a module....

If I ignore 3+4, then I have an almost working version of the build for 
JDK9. There is one strangely instable test, that gives me riddles and 
which I would need to investigate further... but of course we would also 
have to decide what to do about 3 and 4... So far I think we will have 
to deprecate the usage of the system loader for 3. And 4 we have code 
that can take the place of the old code... just I doubt it will work 
properly once modules are everywhere.


bye Jochen



Mime
View raw message