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]
https://github.com/apache/groovy/commit/380ae614ae4d979f00e6e362d210e2dd1295bdce
2016-07-08 16:29 GMT+02:00 John Wagenleitner
<[email protected] <mailto:[email protected]>>:
On Fri, Jul 8, 2016 at 6:58 AM, Russel Winder <[email protected]
<mailto:[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% ....).
