running Groovy on JDK9

[Alan Bateman]

On 10/04/2016 19:29, Jochen Theodorou wrote:
> 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)
There have been a few issues with Gradle using JDK-internal APIs and so 
failing with JDK 9. Several issues have been fixed but maybe not all. I 
see the issue you see mentioned at the end of this thread:

https://discuss.gradle.org/t/jdk9-jigsaw-build-problem/13054

It would be good to check if there is any open bugs on this.


> 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.
The only supported way in JDK 8 and older to extend the class path 
dynamically has been via Instrumentation API.

So for URLClassLoader then were you using setAccessible to get at the 
protected addURL method?

Can you describe the JDBC driver scenario a bit more? Can it be deployed 
as a service provider on the class path? Can it be registered via 
registerDriver?

>
>> :
>>
>> 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/MemberName.java:870)
>> at 
>> java.lang.invoke.MethodHandles$Lookup.checkAccess(java.base at 9-ea/MethodHandles.java:1642)
>> at 
>> java.lang.invoke.MethodHandles$Lookup.checkMethod(java.base at 9-ea/MethodHandles.java:1582)
>> at 
>> java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(java.base at 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.java:96)
>> ... 7 more
>
> Can somebody explain me what the IllegalAccessException means? Why can 
> I not call unreflectSpecial here?
Do you know how this Lookup is created? I'm curious how the lookup mode 
could be "2" (PRIVATE). Running with -esa might reveal more.

-Alan