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

Reply via email to