With the following changes to commit 380ae614 I am able to successfully run ./gradlew :groovy-xml:test and ./gradlew :groovy-templates:test (with all tests passing)
https://github.com/jwagenleitner/groovy/commit/3d3af66e7baf6a5b6ecfc063557f7aaf95a9b38a There's probably a more efficient way to do this, but with this I don't need to export _JAVA_OPTIONS="-Djdk.launcher.addmods=java.xml.bind". On Fri, Jul 8, 2016 at 8:44 AM, Cédric Champeau <[email protected]> wrote: > So I have patched the build to add the correct compile options for `javac` > in case JDK 9 is detected [1]. As the commit message states, groovy-xml > compile gets past compileJava, which is great, but then gets blocked by > groovyc, which doesn't see the javax.xml classes. This seems like a pretty > serious issue for us, because the compiler doesn't know anything about > modules. We thought it would be transparent to us as long as we don't use > modules, but since some classes are not visible by default in the JDK now, > we have a problem because groovyc itself becomes broken. > > Another issue I don't understand is that by hiding the `java.xml.bind` > module by default, to be able to compile, one has to use `addmods`. But > doing so, we're forced to upgrade the target level to 1.9. This is weird, > and breaks backwards compatibility (we set source and target level to 1.6, > so why would the compiler force us to use 1.9???). > > In practice, it means we will have to upgrade our builds and CI > infrastructure to use a different strategy: run the build with Gradle on > whatever JDK we want, but fork a compiler process for compilation that uses > older JDKs. Actually I need to check something else. Maybe by using the > `-release` option of javac we can avoid `addmods` and the 1.9 target level > issue at the same time. > > > [1] > https://github.com/apache/groovy/commit/380ae614ae4d979f00e6e362d210e2dd1295bdce > > 2016-07-08 16:29 GMT+02:00 John Wagenleitner <[email protected]> > : > >> >> >> On Fri, Jul 8, 2016 at 6:58 AM, Russel Winder <[email protected]> >> wrote: >> >>> On Fri, 2016-07-08 at 14:34 +0100, Russel Winder wrote: >>> > Turns out it is not a Groovy or Gradle thing, it seems the Java >>> > executable doesn't like the options it advertises it responds to. >>> > >>> > > > (export _JAVA_OPTIONS="-addmods java.xml.bind" >>> > > > && /home/users/russel/lib.Linux.x86_64/JDK9/bin/java -version) >>> > Unrecognized option: -addmods >>> > Error: Could not create the Java Virtual Machine. >>> > Error: A fatal exception has occurred. Program will exit. >>> >>> >>> Anyone know the difference between _JAVA_OPTIONS and JAVA_OPTIONS? >>> >>> >> >> I believe _JAVA_OPTIONS can be used to pass default options to the JVM >> and takes precedence over command line arguments you would normally want to >> pass to java/javac and other jvm tools. There's also JAVA_TOOL_OPTIONS but >> it is lowest in priority and _JAVA_OPTIONS and command line parameters are >> used first in that order. >> >> I'm not aware of a JAVA_OPTIONS. There is a lot of use of JAVA_OPTS but >> that is not read by any of the JVM tools to my knowledge, unlike the >> _JAVA_OPTIONS and JAVA_TOOL_OPTIONS which there exists code in hotspot to >> read those env vars. JAVA_OPTS seems to be just a conventional name used >> by many scripts use it when they call the java executible (i.e., java >> %JAVA_OPTS% ....). >> > >
