[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: JDK 10 Early Access b33 and JDK 8u162 Early Access b03 are available on jdk.java.net

Le 30/11/2017 à 10:27, dalibor topic a écrit :

> Thanks, Emmanuel - in many of these cases (AspectJ, ICU, Spotbugs,
> Gradle, Scala) the way forward seems to be to upgrade the packaged
> software to the latest upstream version supporting JDK 9, often thanks
> to the patches provided by Chris West and the related efforts to rebuild
> the Debian archive with JDK 9 early access builds.

Easier said than done unfortunately ;) Scala alone is a huge task since
they ditched Ant for SBT as build tool (SBT isn't in Debian yet and
rather difficult to bootstrap). Gradle updates give some good headaches
too. And the AspectJ upgrade requires a more recent version of Eclipse,
a serious blocker for us currently.

> Yeah, that's http://openjdk.java.net/jeps/182 . There have been some
> discussions about adjustments to that policy in light of the new release
> model at
> http://mail.openjdk.java.net/pipermail/jdk-dev/2017-November/000108.html
> but no decision has been made yet.

My humble suggestion would be to never deprecate the old source/target

> That's http://openjdk.java.net/jeps/172 . While the checks are on by
> default, many can be turned off using the option -Xdoclint:none. Please
> see
> https://docs.oracle.com/javase/9/javadoc/javadoc-command.htm#JSJAV-GUID-1ABCA873-009C-4BB4-9490-51A716C8AA56
> for details.

doclint is already disabled by default in Debian, when we upgraded to
OpenJDK 8 it basically killed all the packages providing a javadoc, and
we were certainly not going to fix the documentation of all of these

The new annoyance with javadoc in OpenJDK 9 is the increased severity of
incomplete classpaths. Before javadoc would just complain, now it stops
with an error. We can work around that with the -old parameter, but it
doesn't work with OpenJDK 8. This means that without fixing the
classpath we can't have a package that builds with both OpenJDK 8 & 9.
This complicates the transition because we usually switch the default to
the new JDK once all packages build fine with both versions.

> That's http://openjdk.java.net/jeps/261 - while the EE APIs haven't been
> removed from JDK 9, they need to be explicitly resolved per
> https://docs.oracle.com/javase/9/migrate/toc.htm#JSMIG-GUID-F640FA9D-FB66-4D85-AD2B-D931174C09A3

Here again the parameter that makes it work with JDK 9 doesn't work with
JDK 8. So we have to differentiate the JVM parameters depending on the
version used. Nobody want to do that, and I've seen projects simply
adding back activation.jar to their classpath.

I personally don't understand why JAF is being removed. This barely
saves 80KB in the JDK, it could have stayed there, no one would have

> As such, the way forward for users of such APIs would be to migrate to
> standalone implementations, rather than the one provided in the JDK.

Indeed, JAF is on its way back to Debian: https://bugs.debian.org/883168

> It requires running java with -Xshare:dump on installation. See
> https://mjg123.github.io/2017/10/02/JVM-startup.html for an example and
> https://mjg123.github.io/2017/10/04/AppCDS-and-Clojure.html for an
> example using AppCDS.

Thanks for the reference. I tried the clojure example with our openjdk-8
and openjdk-9 packages but didn't measure a significant difference in
execution time. Does it depend on recent kernel features?

> It's per application, and specified using the -XX:SharedArchiveFile
> option per http://openjdk.java.net/jeps/310 .

A CDS cache per library would be more in line with our packaging
practices. Otherwise the cache would be invalidated every time a
dependency is updated, that doesn't seem very practical. Maybe AOT fits
better the Debian model with one .so deployed along each jar. I'll
probably play with that once the JDK transition is over.

Emmanuel Bourg

Reply to: