Groovy and Java 9

[Duncan Dickinson <me...@duncan.dickinson.name>]

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.

Regards,

Duncan

Re: Groovy and Java 9

[Russel Winder <ru...@winder.org.uk>]

On Wed, 2016-05-25 at 21:35 +0200, Jochen Theodorou wrote:
> […]
> 
> There is ground to suspect that we won´t create callsite caching
> helper 
> methods at runtime using JDK9 and non-indy mode. Did you maybe check 
> performance under JDK9 with and without indy? I would be interested
> in 
> knowing if you see a bigger difference compared to JDK8
> 

I haven't really played with any performance aspects recently. Until
after /dev/summer 2016 (a one day conference not a special device to
bring proper weather to the UK) I really won't have much time to play.
Maybe we should raise this again late-June and give it a go. This would
fit well with me trying to get a GPars 2.0 release out of the door.

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Re: Groovy and Java 9

[Jochen Theodorou <bl...@gmx.org>]

On 25.05.2016 09:14, Russel Winder wrote:
> It is perhaps worth pointing out that some of us have Groovy stuff
> running on JDK9 already. Now that I have a Gradle that runs on JDK9, I
> haven't yet written Groovy code that breaks on JDK9 and requires JDK8,
> but then I haven't tried to use any modules stuff.

There is ground to suspect that we won�t create callsite caching helper 
methods at runtime using JDK9 and non-indy mode. Did you maybe check 
performance under JDK9 with and without indy? I would be interested in 
knowing if you see a bigger difference compared to JDK8

bye Jochen

Re: Groovy and Java 9

[Russel Winder <ru...@winder.org.uk>]

It is perhaps worth pointing out that some of us have Groovy stuff
running on JDK9 already. Now that I have a Gradle that runs on JDK9, I
haven't yet written Groovy code that breaks on JDK9 and requires JDK8,
but then I haven't tried to use any modules stuff.

PS Caveat is that GroovyFX doesn't work on JDK9 yet.

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Re: Groovy and Java 9

[Jochen Theodorou <bl...@gmx.org>]

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