groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From C├ędric Champeau <cedric.champ...@gmail.com>
Subject Re: JDK 9 Jigsaw builds
Date Fri, 08 Jul 2016 15:44:02 GMT
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 <john.wagenleitner@gmail.com>:

>
>
> On Fri, Jul 8, 2016 at 6:58 AM, Russel Winder <russel@winder.org.uk>
> 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% ....).
>

Mime
View raw message