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

[dalibor topic <dalibor.topic@oracle.com>]

On 30.11.2017 14:42, Emmanuel Bourg wrote:
> 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 ;) 

Sadly, yeah.

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

I understand the sentiment. Unfortunately, that would steadily increase 
the maintenance cost of the compiler, while the potential benefit of 
supporting old source/target levels would steadily decrease, since most 
compiler users don't use it to recompile very old sources code with very 
new JDKs.

> 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. 

That won't work with 10 either, unfortunately, since the old doclet has 
(finally) been removed. Please see 
https://bugs.openjdk.java.net/browse/JDK-8177511 for details.

> 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.

In contrast to many third party libraries, the JDK has a very regular 
release cycle, leading to four or more releases per year. Code that we 
don't need to distribute as part of OpenJDK 10, 11, etc is not code we 
have to patch, maintain and update as part of the regular JDK release 
cycle.

Carrying code in the JDK that the JDK itself does not use carries both a 
maintenance cost (we now also need to address the technical debt in X), 
and increases the complexity of design decisions (how should the design 
of a feature interacting with X be if someone uses the JDK version of X, 
rather than the upstream version of X).

> > 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 shouldn't, though ASLR may play a role - what does 
-Xlog:class+load=info say?

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