JDK 9 Early Access with Project Jigsaw, build 135 on 09-14-2016 (#5500)

[Jochen Theodorou]

On 02.10.2016 02:25, Malachi de Ælfweald wrote:
> With build 125, Gradle 3.1 works fine.
> With build 138, I have not yet figured out how to get it running.

The Gradle guys had been very proud of their "we support jdk9" story, 
but #AwkwardStrongEncapsulation really destroyed that for them... for 
now at least.

> Trying to run 'gradle init' in a bare directory results in
> 'java.lang.ExceptionInInitializerError'
>
> Adding '-Dsun.reflect.debugModuleAccessChecks=true' it reported:
> 16:56:47.501 [ERROR] [system.err]
> java.lang.reflect.InaccessibleObjectException: Unable to make protected
> java.lang.Package[] java.lang.ClassLoader.getPackages() accessible: module
> java.base does not "exports private java.lang" to unnamed module @352c1b98
>
> I changed the _JAVA_OPTIONS to
> '--add-exports-private=java.base/java.lang=ALL-UNNAMED
> --add-modules=ALL-SYSTEM --add-exports=java.base/sun.nio.ch=ALL-UNNAMED'
> (the last two are for Dagger and Neo4j compat)
> That resulted in:
> Unable to get mutable environment variable map.
>
> This appears to come from a setAccessible from inside getEnv
> https://github.com/adammurdoch/native-platform/blob/master/src/main/java/net/rubygrapefruit/platform/internal/WrapperProcess.java#L113

adding --add-exports-private java.base/java.util=ALL-UNNAMED can help a 
bit here and there. Adding the same options above to the 
"org.gradle.jvmargs" in gradle.properties if you fork might too.

And even though this will solve the problem in parts of Gradle, it will 
not solve the problem in the Groovy code called by Gradle. Because 
before I had a logic, that if not all methods can be made accessible, I 
skip the class when creating the meta class and use only the superclass 
and interface information. This logic worked fine with SecurityManagers 
and with the module logic before #AwkwardStrongEncapsulation. Now with 
#AwkwardStrongEncapsulation I have to go through each method and make it 
accessible piece by piece. Without this change the --add-exports-private 
is going to be quite long I imagine... and I am not convinced yet, that 
this solution will work in all relevant cases. It for sure is no 
solution for modules written in Groovy - should they ever come. An 
option to completely turn off #AwkwardStrongEncapsulation would be nice.

> So how do we get past #AwkwardStrongEncapsulation?  Do I need to fork
> Gradle's dependencies and rebuild both of them since I have no code of my
> own in this use case?

you can try making Gradle use Groovy master plus the above. I can´t say 
if it will work then though, haven´t tried that yet.

bye Jochen