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 levels. > 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 packages. 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 complained. > 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
