JDK9 Jigsaw build problem

Bugs
1

Gradle 2.8
When building with jake (JDK9 jigsaw), the following internal classes are used.
sun.net.www.protocol.file.FileURLConnection
sun.net.www.URLConnection
sun.nio.fs.UnixPath

These need to be removed to avoid unnecessary exports for the build.
Thanks.

2

We’re working on full JDK9 support: https://github.com/gradle/gradle/blob/master/design-docs/jdk9-support.md

We can already run Gradle with non-Jigsaw JDK9: https://builds.gradle.org/project.html?projectId=Gradle_Master_CoveragePhase_LinuxCoverage_LinuxJava19&tab=projectOverview&guest=1

The plan is to support using Jigsaw JDK9 to compile (while running Gradle with non-Jigsaw JDK9) first.

3

Needs to be updated for Java 9-ea+95. (Non-Jigsaaw)

$ gradle --info --stacktrace clean install

FAILURE: Build failed with an exception.

* What went wrong:
Could not determine java version from '9-ea'.

* Try:
Run with --debug option to get more log output.

* Exception is:
java.lang.IllegalArgumentException: Could not determine java version from '9-ea'.
	at org.gradle.api.JavaVersion.toVersion(JavaVersion.java:63)
	at org.gradle.api.JavaVersion.current(JavaVersion.java:72)
	at org.gradle.launcher.cli.JavaRuntimeValidationAction.execute(JavaRuntimeValidationAction.java:32)
	at org.gradle.launcher.cli.JavaRuntimeValidationAction.execute(JavaRuntimeValidationAction.java:24)
	at org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:206)
	at org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:169)
	at org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:33)
	at org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:22)
	at org.gradle.launcher.Main.doAction(Main.java:33)
	at org.gradle.launcher.bootstrap.EntryPoint.run(EntryPoint.java:45)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:520)
	at org.gradle.launcher.bootstrap.ProcessBootstrap.runNoExit(ProcessBootstrap.java:54)
	at org.gradle.launcher.bootstrap.ProcessBootstrap.run(ProcessBootstrap.java:35)
	at org.gradle.launcher.GradleMain.main(GradleMain.java:23)
4

@swpalmer: this is fixed now. The fix will be in Gradle 2.10.

5

Gradle 2.10-rc-1 will not invoke the compiler under jake nightly build:

Caused by: java.lang.IllegalAccessException: class org.gradle.internal.reflect.DirectInstantiator cannot access class com.sun.tools.javac.api.JavacTool (in module jdk.compiler) because module jdk.compiler does not export com.sun.tools.javac.api to unnamed module @1d371b2d
at org.gradle.internal.reflect.DirectInstantiator.newInstance(DirectInstantiator.java:49)
… 93 more

6

You need some JVM configuration like

GRADLE_OPTS=“-XaddExports:jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED”

A sample project: GitHub - torstenwerner/java-9-no-jar-hell: Using ModuleLayer instances to load conflicting versions of the same jar in the same JVM.

7

When will the sun.net.www.protocol.file.FileURLConnection problem in the daemon be fixed?
We are trying to reduce our exports to 0.

8

For projects that spawn compiler daemons, follow this solution: Gradle Compiler Daemon jvm opts [solved]