running Groovy on JDK9

[Stephen Felts]

On the other hand, in a gradle script, you can't use

options.compilerArgs << '@/pathname/argsfile'

because it will be put into a JDK9 arg file and JDK9 doesn't support an arg file within an argfile.
I think that JDK9 should be fixed to support that (and properly handle recursion).


-----Original Message-----
From: Stephen Felts 
Sent: Sunday, April 10, 2016 3:50 PM
To: Jochen Theodorou; jigsaw-dev at openjdk.java.net
Subject: RE: running Groovy on JDK9

You should start with Gradle 2.10.  It has most of the fixes needed to run with JDK9.

I found that it was easiest to run with an argument file (though originally I had it all on the command line).
It's needed for both gradle and the daemon.

export GRADLE_OPTS="@${argsfile} -Xmx2048m -Dorg.gradle.jvmargs=\"@${argsfile} -Xmx2048m \" "

The options that you need will vary depending on your application.





-----Original Message-----
From: Jochen Theodorou [mailto:blackdrag at gmx.org]
Sent: Sunday, April 10, 2016 2:30 PM
To: jigsaw-dev at openjdk.java.net
Subject: running Groovy on JDK9

Hi all,

today I had a few hours spare time and decided to invest that in trying to make the Groovy build compile and run tests. I am not trying to make a module on my own yet.

for compilation to work my biggest problem was the direct usage of the javac compiler set through gradle. Which is why I had to add

options.forkOptions.jvmArgs << > options.forkOptions.jvmArgs << "-XaddExports:jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED"

for compileJava and
> groovyOptions.forkOptions.jvmArgs << "-XaddExports:jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED"

for the groovy compiler (which uses internally he compiler set through
gradle)

those simple changes (and removing the deprecated jvm options) get me past compilation and into test execution, which completes with 47 failures (of 8566 tests). First error I get is something like this:

>  Compile error during compilation with javac.
> /tmp/stubgentests77510877964035184621460309483098/bar/GroovyClass.java
> :12: error: package groovy.lang does not exist 
> groovy.lang.GroovyObject {

as an explanation.. at this point there should be a groovy.jar containing GroovyObject on the classpath. There is a GroovyClass.groovy, for which a GroovyClass.java stub is produced. The stub is then used during the compilation of java sources, that depend on groovy sources and the other way around. The stub does have only dummy code. But I am wondering why this compilation fails. We do use the sources option during compilation with javac and javac finds them.. only it seems those sources have no access to the groovy.jar

Then of course we have something like this:
> org.codehaus.groovy.runtime.m12n.ExtensionModuleTest > testThatModuleCanBeLoadedWithGrab FAILED
>     java.lang.RuntimeException: Unable to find class loader

(module here has nothing to do with jigsaw. This error is caused by not using an URLClassloader anymore in JDK9... I actually would like to know what the jdk9 way of doing this is supposed to be. What I mean is that you had the not really supported option of adding a jar to the highest loader and make its classes available to lower loaders that way. Since that loader is no URLClassloader anymore, this does not work any longer. 
But is there any way to simulate that? Main usage was for example loading a sql driver jar via Class.forName and the driver then registering itself in the static constructor. How am I supposed to dynamically load database drivers in JDK9 (even if they are not written for JDK9)? Would be one question. But this extends to jars loaded at runtime, not through command line options containing services in general actually.

And then I have this one:
>
> org.codehaus.groovy.runtime.InterfaceConversionTest > 
> testDefaultInterfaceMethodCallOnProxy FAILED BUG! UNCAUGHT EXCEPTION:
> access to public member failed: 
> java.util.Comparator.reversed()Comparator/invokeSpecial, from
> java.util.Comparator/2 (module java.base) at 
> org.codehaus.groovy.vmplugin.v7.Java7.getInvokeSpecialHandle(Java7.jav
> a:99) at
> org.codehaus.groovy.runtime.ConversionHandler.invoke(ConversionHandler
> .java:109) at com.sun.proxy.$Proxy47.reversed(Unknown Source) at 
> java_util_Comparator$reversed$0.call(Unknown Source) at 
> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSit
> eArray.java:48) at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCal
> lSite.java:113) at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCal
> lSite.java:117) at
> org.codehaus.groovy.runtime.InterfaceConversionTest.testDefaultInterfa
> ceMethodCallOnProxy(InterfaceConversionTest.groovy:52)
>
> Caused by:
> java.lang.IllegalAccessException: access to public member failed: 
> java.util.Comparator.reversed()Comparator/invokeSpecial, from
> java.util.Comparator/2 (module java.base) at 
> java.lang.invoke.MemberName.makeAccessException(java.base at 9-ea/MemberN
> ame.java:870) at
> java.lang.invoke.MethodHandles$Lookup.checkAccess(java.base at 9-ea/Metho
> dHandles.java:1642) at
> java.lang.invoke.MethodHandles$Lookup.checkMethod(java.base at 9-ea/Metho
> dHandles.java:1582) at
> java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(java.base@
> 9-ea/MethodHandles.java:1731) at
> java.lang.invoke.MethodHandles$Lookup.getDirectMethodNoSecurityManager
> (java.base at 9-ea/MethodHandles.java:1725)
> at
> java.lang.invoke.MethodHandles$Lookup.unreflectSpecial(java.base at 9-ea/
> MethodHandles.java:1336) at
> org.codehaus.groovy.vmplugin.v7.Java7.getInvokeSpecialHandle(Java7.jav
> a:96)
> ... 7 more

Can somebody explain me what the IllegalAccessException means? Why can I not call unreflectSpecial here?


bye Jochen