[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

On 29.11.2017 14:22, Emmanuel Bourg wrote:
Le 29/11/2017 à 13:30, dalibor topic a écrit :

I think what makes Debian GNU/Linux interesting for us regarding the
OpenJDK Quality Outreach is that it's one of the first Linux
distributions to do mass rebuilds of its (quite substantial) package
archive with JDK 9. So it has the means and the knowledge among its
contributors to potentially provide valuable perspectives about the
impact of individual changes planned for future OpenJDK releases (JDK
10, etc.) that go beyond what individual FOSS projects can.

FYI we have a list of bugs to be addressed to complete the transition to
Java 9:


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.

More general information on migrating to JDK 9 is available at https://docs.oracle.com/javase/9/migrate/toc.htm#JSMIG-GUID-7744EF96-5899-4FB2-B34E-86D49B2E89B6

The removal of the old source/target in javac,

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.

the increasing strictness
of javadoc

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.

and the removal of APIs (javax.xml.bind, javax.activation)
have been the most disrupting changes so far.

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 .

The EE APIs have been deprecated for removal, though, and there is a draft JEP at http://openjdk.java.net/jeps/8189188 elaborating on that - their removal is not yet scheduled for any specific release, though.

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.

We haven't started testing with OpenJDK 10 yet. Matthias has uploaded
the openjdk-10 package to experimental last week. I guess we'll start
mass rebuilds with JDK 10 once the JDK 9 issues are under control.

According to the JDK 10 schedule at http://openjdk.java.net/projects/jdk/10/ the rampdown phase for JDK 10 will start mid-December. Before rampdown is often the best time to provide feedback on features and their design and implementation, while after rampdown is a good time to provide feedback on regressions.
We don't ship classes.jsa with OpenJDK yet, I don't know if there is a
reason for that. Does it require a specific parameter when building OpenJDK?

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.
Shipping an extra arch-specific package containing the AppCDS file for
each worthy application shouldn't be too difficult. I'm not sure how it
would play with package dependencies though. Is there a unique .jsa file
for the application, or one per library?

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

What happens if the classes in
the jsa files don't match the classes in the jar files? Is the data
automatically invalidated and ignored?

Yes. If -Xshare:on is used, then the VM will exit when it detects a discrepancy (different classpath, etc.) or if it can't mmap the shared archive. With -Xshare:auto, it'll ignore the shared archive file, and load the classes as usual.

dalibor topic

<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961

ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher

<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment

Reply to: