----- Mail original ----- > De: "Jochen Theodorou" <[email protected]> > À: [email protected] > 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 > > <[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% ....). > > > > > >
