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:blackd...@gmx.org]
Sent: Sunday, April 10, 2016 2:30 PM
To: jigsaw-dev@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@9-ea/MemberN
> ame.java:870) at
> java.lang.invoke.MethodHandles$Lookup.checkAccess(java.base@9-ea/Metho
> dHandles.java:1642) at
> java.lang.invoke.MethodHandles$Lookup.checkMethod(java.base@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@9-ea/MethodHandles.java:1725)
> at
> java.lang.invoke.MethodHandles$Lookup.unreflectSpecial(java.base@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
