Re: JDK 10 Early Access b33 and JDK 8u162 Early Access b03 are available on jdk.java.net
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
The removal of the old source/target in javac, the increasing strictness
of javadoc and the removal of APIs (javax.xml.bind, javax.activation)
have been the most disrupting changes so far.
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.
> For example, a planned feature for JDK 10 is application class data
> sharing ("AppCDS"), which extends the existing Class-Data Sharing [3]
> ("CDS") feature in OpenJDK to allow application classes to be placed in
> the shared archive to improve startup and footprint. Fedora OpenJDK
> packages use CDS already, afaict from the existence of classes.jsa in
> their package file lists. [1]
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?
> I don't know if Debian's OpenJDK packages do - if they don't then that,
> in conjunction with AppCDS in JDK 10, might be an interesting feature to
> try out in order to attempt to decrease startup costs for development
> tools written in Java
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? 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?
Emmanuel Bourg
Reply to: