groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Wagenleitner <>
Subject Re: JDK 9 Jigsaw builds
Date Fri, 08 Jul 2016 18:14:18 GMT
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)

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 <>

> 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]
> 2016-07-08 16:29 GMT+02:00 John Wagenleitner <>
> :
>> On Fri, Jul 8, 2016 at 6:58 AM, Russel Winder <>
>> 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
>>> > 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% ....).

View raw message