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
