groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remi Forax <fo...@univ-mlv.fr>
Subject Re: JDK 9 Jigsaw builds
Date Sat, 09 Jul 2016 07:03:18 GMT


----- Mail original -----
> De: "Jochen Theodorou" <blackdrag@gmx.org>
> À: dev@groovy.apache.org
> Envoyé: Vendredi 8 Juillet 2016 21:51:18
> Objet: Re: JDK 9 Jigsaw builds
> 
> actually, I think I did see somewhere that JDK9 will support only 8 and
> 7 as targets. Maybe someone can confirm that.

not at all !

It's not the JDK, it's just javac.
javac only support 4 releases, it's not something new, i think that policy was introduced
with javac 7,
to be able to remove old code. So javac 9 support 9, 8, 7, and 6. And for the last supported
platform, javac emits a warning.

so on my laptop,

$ /usr/jdk/jdk-9/bin/javac -source 1.5 Foo.java 
warning: [options] bootstrap class path not set in conjunction with -source 1.5
error: Source option 1.5 is no longer supported. Use 1.6 or later.

$ /usr/jdk/jdk-9/bin/javac -source 1.6 Foo.java 
warning: [options] bootstrap class path not set in conjunction with -source 1.6
warning: [options] source value 1.6 is obsolete and will be removed in a future release
warning: [options] To suppress warnings about obsolete options, use -Xlint:-options.
3 warnings

cheers,
Rémi

> 
> 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
> > <john.wagenleitner@gmail.com <mailto:john.wagenleitner@gmail.com>>:
> >
> >
> >
> >     On Fri, Jul 8, 2016 at 6:58 AM, Russel Winder <russel@winder.org.uk
> >     <mailto: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