groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <>
Subject Re: JDK 9 Jigsaw builds
Date Fri, 08 Jul 2016 19:51:18 GMT
actually, I think I did see somewhere that JDK9 will support only 8 and 
7 as targets. Maybe someone can confirm that.

On 08.07.2016 17:44, C├ędric Champeau 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]
> 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