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

[Malachi de Ælfweald]

With build 125, Gradle 3.1 works fine.
With build 138, I have not yet figured out how to get it running.

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

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?




Malachi de Ælfweald
http://www.google.com/profiles/malachid

On Thu, Sep 15, 2016 at 10:07 AM, Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> The EA download [1] has been refreshed with new builds that are mostly
> aligned with the current proposals for JPMS issues [2]. Not everything is
> there yet of course (and some areas need a few more iterations) but there
> is enough to test and try things out.
>
> For #ReflectiveAccessToNonExportedTypes and #AwkwardStrongEncapsulation
> then the initial support for `weak module` and `exports private` is in
> place. These are probably the highest priority changes to try out.
>
> The changes to setAccessible in #AwkwardStrongEncapsulation is going to be
> disruptive and will no doubt expose hacks in many areas. We've run into
> several of these already. The command line option to allow existing code to
> break into non-public types/members is --add-exports-private. The format of
> the value passed to this option is the same--add-exports. With
> #AddExportsInManifest then there are equivalents in the application JAR
> main manifest to try out too.
>
> As part of the #ClassLoaderNames then the format of the stack trace
> elements has changed.
>
> For #ServiceLoaderEnhancements then the implementation is mostly aligned,
> except for the static factory method which needs an update to javac and SL
> to align with the proposal (should be there soon, just not in this build).
>
> Several people have brought up #ResourceEncapsulation and
> #ClassFilesAsResources here so it would be good to try this out.
>
> As always, the most valuable feedback is from those trying out the builds
> so please let us know what you have tried and what works or doesn't work.
>
> -Alan
>
> [1] https://jdk9.java.net/jigsaw/
> [2] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-Septe
> mber/009365.html
>