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:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=default-java9;users=debian-java@lists.debian.org
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.
cheers,
dalibor topic
--
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+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: