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

[dalibor topic]

On 13.12.2017 11:13, Emmanuel Bourg wrote:

Hi Dalibor,

Le 01/12/2017 à 11:12, dalibor topic a écrit :


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.


There is an undocumented --ignore-source-errors flag in javadoc since
Java 9 that could compensate for the loss of the old doclet. Do you know
if this flag will be kept in future releases? 


If it's undocumented, then it could be removed at any point. If you find 
the functionality useful, I'd suggest bringing it up on 
http://mail.openjdk.java.net/mailman/listinfo/javadoc-dev in order to 
discuss if there is a better way to make use of it than a hidden option.


It seems that this option came into javadoc as part of 
http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/95d65add96a9 . The 
corresponding JBS issue is 
https://bugs.openjdk.java.net/browse/JDK-8175219 , and the motivation 
behind it were errors in source code, rather than making javadoc a bit 
less strict, fwiw.


On a mildly related side note, in 10, javadoc treats failure to access a 
'-link-ed' URL as an error, not a warning. 
https://bugs.openjdk.java.net/browse/JDK-8180019 .


cheers,
dalibor topic


That would help us greatly.

Emmanuel Bourg



--
 Dalibor Topic | Principal Product Manager
Phone: +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

 Oracle is committed to developing
practices and products that help protect the environment

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

[Emmanuel Bourg]

Hi Dalibor,

Le 01/12/2017 à 11:12, dalibor topic a écrit :

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

There is an undocumented --ignore-source-errors flag in javadoc since
Java 9 that could compensate for the loss of the old doclet. Do you know
if this flag will be kept in future releases? That would help us greatly.

Emmanuel Bourg

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

[dalibor topic]

On 30.11.2017 15:08, Emmanuel Bourg wrote:

If there is no hurry to remove javah I suggest waiting until JDK 12 to
do so, this would increase our chances to include JDK 11 in the next
Debian release.


I don't think that hurry is necessarily a factor here, given that javah 
would have been deprecated for about 4 years prior to its potential 
removal in JDK 10. Waiting to remove it until JDK 12 would make that 5 
years of deprecation instead of 4.


If developers of an open source project have ignored a javah removal 
warning message for four years, I assume that they might just as well 
ignore it for five years, too, ultimately leaving downstream packagers 
in the same situation.


Instead, what I think would be really useful, if you'd like to make a 
case for a delay of this particular change, would be to find out the 
kind of cases where moving projects to use javac -h instead isn't 
feasible for some reason or other. Those cases would then be good items 
to discuss on the jdk-dev list.


cheers,
dalibor topic
--
 Dalibor Topic | Principal Product Manager
Phone: +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

 Oracle is committed to developing
practices and products that help protect the environment

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

[dalibor topic]

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

--
 Dalibor Topic | Principal Product Manager
Phone: +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

 Oracle is committed to developing
practices and products that help protect the environment

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

[Emmanuel Bourg]

Le 29/11/2017 à 14:32, dalibor topic a écrit :

> Does java-package work for JDK 10 EA builds?

Not yet but it definitely will.


> An alternative to javah has been available with the -h flag for javac since 
> JDK 8

Great, so we can start the transition now. It might be nice to add some
examples of the javac -h syntax in the javah documentation to ease the
migration.


> It might be removed in JDK 10 (2018). If you have a good sense
> how much affected Debian would be by this change, that would be great
> feedback to share on the thread at
> http://mail.openjdk.java.net/pipermail/jdk-dev/2017-November/000278.html .

If Chris still has the logs of its latest mass rebuild I think we could
easily identify the affected packaged by grepping the message "Warning:
The javah tool is planned to be removed".

If there is no hurry to remove javah I suggest waiting until JDK 12 to
do so, this would increase our chances to include JDK 11 in the next
Debian release.


> A jdeprscan -for-removal run might be a useful check to consider adding
> to lintian, for example.

Good idea, I don't know if Lintian can optionally depend on the JRE though.

Emmanuel Bourg

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

[Emmanuel Bourg]

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

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

[dalibor topic]

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

--
 Dalibor Topic | Principal Product Manager
Phone: +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

 Oracle is committed to developing
practices and products that help protect the environment

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

[dalibor topic]

On 29.11.2017 12:46, Emmanuel Bourg wrote:

Le 29/11/2017 à 10:32, dalibor topic a écrit :


I'd agree with Matthias that the binaries of some builds are not by
themselves newsworthy for the debian-java mailing list specifically,
since Debian doesn't use third party binaries in its Java packaging.


Actually these binaries can be turned into Debian packages with the
java-package tool. 


Thanks, Emmanuel - I didn't expect that to necessarily be the case, 
since the package description at 
https://packages.debian.org/es/sid/java-package only claims support up 
to Oracle JDK 8, and it seems that support for Oracle JDK 9 is WIP: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=876426


Does java-package work for JDK 10 EA builds?


For example a feature should be removed in the upcoming LTS
release only if it was deprecated (with an alternative available) in the
latest LTS. So for javah that would mean deprecated until Java 11, and
removed in Java 12 (for the next Java 17 LTS).


An alternative to javah has been available with the -h flag for javac since
JDK 8 (2014). It might be removed in JDK 10 (2018). If you have a good 
sense
how much affected Debian would be by this change, that would be great 
feedback to share on the thread at 
http://mail.openjdk.java.net/pipermail/jdk-dev/2017-November/000278.html .


That being said, the OpenJDK policy for removals of deprecated 
functionality is not tied to LTS releases. Whether it should be would be 
an interesting discussion to have on the jdk-...@openjdk.java.net 
mailing list. For some background on enhancements to deprecation 
(policies) since JDK 9, see http://openjdk.java.net/jeps/277 .


Meanwhile, JDK 9 comes with the jdeprscan tool, which can be useful in 
the context of detection of potential future issues with third party 
code using deprecated APIs. Please see 
https://docs.oracle.com/javase/9/tools/jdeprscan.htm#JSWOR-GUID-2B7588B0-92DB-4A88-88D4-24D183660A62 
for a reference in general, and the -for-removal flag in particular.


A jdeprscan -for-removal run might be a useful check to consider adding 
to lintian, for example.

Having the mails on the debian-java list is an
opportunity to provide feedback in the Debian context and have more
developers joining the discussion. That would be lost with direct emails.


Indeed, but if someone feels that the early access announcement mails 
are inappropriate for a list they subscribed to, then I don't think that 
it's a good idea to send them further emails of the same kind.


To be successful, the OpenJDK Quality Outreach depends on the good will 
of the open source developers and communities it engages with. 
Encouraging open source community developers to test and report issues 
as well as provide feedback on upcoming OpenJDK releases can't work if 
it's perceived as annoying or misplaced.


Which is why I proposed some modifications to the format of the e-mails 
to potentially make them more useful for Matthias. Let's see what he 
thinks first.


cheers,
dalibor topic

--
 Dalibor Topic | Principal Product Manager
Phone: +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

 Oracle is committed to developing
practices and products that help protect the environment

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

[Emmanuel Bourg]

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

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

[tony mancill]

On Wed, Nov 29, 2017 at 12:46:20PM +0100, Emmanuel Bourg wrote:
> Le 29/11/2017 à 10:32, dalibor topic a écrit :
> > If not, then I'd suggest stopping further early access announcements
> > mails to this mailing list, Rory, and sending them to Emmanuel directly
> > instead, while anyone else interested in them could also subscribe to
> > the quality-disc...@openjdk.java.net mailing list and receive, comment
> > and discuss them that way.
> 
> I'm moderately interested in receiving these emails directly since I
> already happen to read them on the Tomcat, Apache Commons and Maven
> mailing lists. Having the mails on the debian-java list is an
> opportunity to provide feedback in the Debian context and have more
> developers joining the discussion. That would be lost with direct emails.

Speaking only for myself, I find the emails interesting and don't feel
that they've crossed the signal -> noise threshold.  However, if there
is strong consensus to the contrary, I will subscribe to the
quality-discuss list mentioned above.  Thank you for the pointer!

Cheers,
tony


signature.asc
Description: PGP signature

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

[dalibor topic]

On 29.11.2017 10:20, Emmanuel Bourg wrote:

From my experience on other lists also receiving these
notifications I know this is a good opportunity to gather and take into
account the community feedback. 


That's the general idea, yeah!

A list of FOSS projects participating in the OpenJDK quality outreach is 
available at 
https://wiki.openjdk.java.net/display/quality/Quality+Outreach . Not all 
of them necessarily chose to receive the early access announcement mails 
on their mailing lists, fwiw.


The last six monthly report on the outreach activities can be found at 
https://wiki.openjdk.java.net/display/quality/Quality+Outreach+report+September+2017 
, and the recording of the 2017 FOSDEM Java dev room talk on it can be 
found at https://archive.fosdem.org/2017/schedule/event/outreach/ .


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.


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]


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, which might be relevant in the context of 
building and testing FOSS packages.


AppCDS was pushed to the JDK (10) Hotspot forest yesterday [2], so it 
should become available in a JDK 10 early access build in due time.


cheers,
dalibor topic

[0] http://openjdk.java.net/jeps/310
[1] 
https://www.rpmfind.net/linux/RPM/fedora/devel/rawhide/x86_64/j/java-1.8.0-openjdk-headless-1.8.0.151-1.b12.fc28.x86_64.html

[2] http://hg.openjdk.java.net/jdk/hs/rev/78b2ecdd3c4b
[3] 
https://docs.oracle.com/javase/9/vm/class-data-sharing.htm#JSJVM-GUID-7EAA3411-8CF0-4D19-BD05-DF5E1780AA91

--
 Dalibor Topic | Principal Product Manager
Phone: +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

 Oracle is committed to developing
practices and products that help protect the environment

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

[Emmanuel Bourg]

Le 29/11/2017 à 10:32, dalibor topic a écrit :

> I'd agree with Matthias that the binaries of some builds are not by
> themselves newsworthy for the debian-java mailing list specifically,
> since Debian doesn't use third party binaries in its Java packaging.

Actually these binaries can be turned into Debian packages with the
java-package tool. The resulting packages can then be used to rebuild
the Debian packages and have a glimpse of the next compatibility issues
we'll face.


> I'd also agree with Emmanuel that it can be useful for packagers to be
> aware of upcoming changes in the JDK sooner, so that they can provide
> feedback and make adjustments as necessary. For example, the javah tool
> is considered for removal in JDK 10 [0], which may or may not impact
> some packages in Debian. For the corresponding thread on the Apache Ant
> mailing list, please see
> http://mail-archives.apache.org/mod_mbox/ant-dev/201711.mbox/browser .

These API/tools removals since Java 9 are hitting us really hard. Debian
rebuilds from source a wide range of Java projects, some of them are
rather old, barely maintained upstream but nonetheless still useful. We
are often forced to port the projects to build with the recent JDKs
before the upstream developers adapt their code (and if they ever do).
We are happy to contribute patches but the process doesn't scale and
it's difficult to keep up. At this point we aren't even sure if we'll be
able to switch to Java > 8 for the next Debian release in 2019.

It would be nice if the JDK had a longer transition phase for the
removals. For example a feature should be removed in the upcoming LTS
release only if it was deprecated (with an alternative available) in the
latest LTS. So for javah that would mean deprecated until Java 11, and
removed in Java 12 (for the next Java 17 LTS).


> If not, then I'd suggest stopping further early access announcements
> mails to this mailing list, Rory, and sending them to Emmanuel directly
> instead, while anyone else interested in them could also subscribe to
> the quality-disc...@openjdk.java.net mailing list and receive, comment
> and discuss them that way.

I'm moderately interested in receiving these emails directly since I
already happen to read them on the Tomcat, Apache Commons and Maven
mailing lists. Having the mails on the debian-java list is an
opportunity to provide feedback in the Debian context and have more
developers joining the discussion. That would be lost with direct emails.

Emmanuel Bourg

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

[dalibor topic]

I think that as soon as someone objects to having mail sent to a public 
list, the sending should end.


I'd agree with Matthias that the binaries of some builds are not by 
themselves newsworthy for the debian-java mailing list specifically, 
since Debian doesn't use third party binaries in its Java packaging.


I'd also agree with Emmanuel that it can be useful for packagers to be 
aware of upcoming changes in the JDK sooner, so that they can provide 
feedback and make adjustments as necessary. For example, the javah tool 
is considered for removal in JDK 10 [0], which may or may not impact 
some packages in Debian. For the corresponding thread on the Apache Ant 
mailing list, please see 
http://mail-archives.apache.org/mod_mbox/ant-dev/201711.mbox/browser .


So in light of Matthias' well-founded objection, I'm wondering if these 
kind of emails wouldn't be more useful to the Debian Java community if 
they, in addition to pointers to binaries, also included instructions on 
checking out the tagged sources for OpenJDK for the specific builds, so 
that feedback by so inclined Debian developers could also be provided on 
whether the upstream source code builds at all on Debian GNU/Linux 
(which may be well ahead of the Oracle developers in terms of the native 
GCC toolchains used, for example).


Matthias, would that be more useful and acceptable?

If not, then I'd suggest stopping further early access announcements 
mails to this mailing list, Rory, and sending them to Emmanuel directly 
instead, while anyone else interested in them could also subscribe to 
the quality-disc...@openjdk.java.net mailing list and receive, comment 
and discuss them that way.


cheers,
dalibor topic

[0] http://mail.openjdk.java.net/pipermail/jdk-dev/2017-November/000278.html

--
 Dalibor Topic | Principal Product Manager
Phone: +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

 Oracle is committed to developing
practices and products that help protect the environment

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

[Emmanuel Bourg]

Hi Rory,

Le 29/11/2017 à 10:01, Rory O'Donnell a écrit :

> If you want me to stop sending emails to this list let me know ?

I'm personally glad that you send these emails to the debian-java list.
They are sent barely once or twice a month and contain useful
information. From my experience on other lists also receiving these
notifications I know this is a good opportunity to gather and take into
account the community feedback. So I hope the other contributors here
will agree to keep this communication canal open.

Emmanuel Bourg

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

[Rory O'Donnell]

Hi Emmanuel,

If you want me to stop sending emails to this list let me know ?

Rgds,Rory


On 29/11/2017 08:12, Emmanuel Bourg wrote:

Le 29/11/2017 à 02:16, Matthias Klose a écrit :


is it really necessary to have these advertisements of Oracle's binary only,
architecture limited builds on a mailing list of a community project dedicated
to build binaries from sources?  I can't find such advertisements on e.g.
mailing lists for the Fedora project either.

Hi Matthias,

Oracle is advertising the EA build on the lists of many open source
projects (Apache, Eclipse, Hibernate...). I requested the debian-java
list to be included because the announces often summarize the important
changes to the Java ecosystem that we'll have to deal with in the near
future. I wasn't aware of the java.security.acl deprecation for example,
and this is hitting ~10 packages.

Emmanuel Bourg


--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland

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

[Emmanuel Bourg]

Le 29/11/2017 à 02:16, Matthias Klose a écrit :

> is it really necessary to have these advertisements of Oracle's binary only,
> architecture limited builds on a mailing list of a community project dedicated
> to build binaries from sources?  I can't find such advertisements on e.g.
> mailing lists for the Fedora project either.

Hi Matthias,

Oracle is advertising the EA build on the lists of many open source
projects (Apache, Eclipse, Hibernate...). I requested the debian-java
list to be included because the announces often summarize the important
changes to the Java ecosystem that we'll have to deal with in the near
future. I wasn't aware of the java.security.acl deprecation for example,
and this is hitting ~10 packages.

Emmanuel Bourg

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

[Matthias Klose]

Rory, Dalibor,

is it really necessary to have these advertisements of Oracle's binary only,
architecture limited builds on a mailing list of a community project dedicated
to build binaries from sources?  I can't find such advertisements on e.g.
mailing lists for the Fedora project either.

Thanks, Matthias


On 28.11.2017 16:45, Rory O'Donnell wrote:
> Hi All,
> 
> *JDK 10 Early Access  build 33 is available at : - **jdk.java.net/10/*
> 
> 
> Notable changes since previous email.
> 
> JDK-8180019
>  - *javadoc treats failure to
> access a URL as an error , not a warning.*
> If javadoc cannot access the contents of a URL provided with the -link or
> -linkoffline options,the tool will now report an error.
> Previously, the tool continued with a warning, producing incorrect 
> documentation
> output.
> 
> JDK-8175094 *- **The
> java.security.acl APIs are deprecated, for removal
> * The deprecated java.security.acl APIs are now marked with forRemoval=true 
> and
> are subject to removal in a future version of Java SE.
> 
> JDK-8175091  *- The
> java.security.{Certificate,Identity,IdentityScope,Signer} APIs are deprecated,
> for removal*
> The deprecated java.security.{Certificate, Identity, IdentityScope, Signer}
> classes are now marked with forRemoval=true and are subject to removal in a
> future version of Java SE.
> 
> JDK 10 Schedule, Status & Features are available [1]
> 
> 
>  Notes
> 
>  * OpenJDK EA binaries will be available at a later date.
>  * Oracle has proposed: Newer version-string scheme for the Java SE
>    Platform and the JDK
>  o Please see Mark Reinhold's proposal [2]
> 
> *JDK 8u162 Early Access build 03 is available at :- http://jdk.java.net/8/*
> 
> 
> 
> *Feedback* - If you have suggestions or encounter bugs, please submit them 
> using
> the usual Java SE bug-reporting channel.
> Be sure to include complete version information from the output of the |java
> --version| command.
> 
> Regards,
> Rory
> 
> [1] http://openjdk.java.net/projects/jdk/10/
> [2] http://mail.openjdk.java.net/pipermail/jdk-dev/2017-November/89.html
> 

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

[Rory O'Donnell]

Hi All,

*JDK 10 Early Access  build 33 is available at : - **jdk.java.net/10/*


Notable changes since previous email.

JDK-8180019 
 - *javadoc treats 
failure to access a URL as an error , not a warning.*
If javadoc cannot access the contents of a URL provided with the -link 
or -linkoffline options,the tool will now report an error.
Previously, the tool continued with a warning, producing incorrect 
documentation output.


JDK-8175094 *- **The 
java.security.acl APIs are deprecated, for removal
* The deprecated java.security.acl APIs are now marked with 
forRemoval=true and are subject to removal in a future version of Java SE.


JDK-8175091  *- The 
java.security.{Certificate,Identity,IdentityScope,Signer} APIs are 
deprecated, for removal*
The deprecated java.security.{Certificate, Identity, IdentityScope, 
Signer} classes are now marked with forRemoval=true and are subject to 
removal in a future version of Java SE.


JDK 10 Schedule, Status & Features are available [1]


 Notes

 * OpenJDK EA binaries will be available at a later date.
 * Oracle has proposed: Newer version-string scheme for the Java SE
   Platform and the JDK
 o Please see Mark Reinhold's proposal [2]

*JDK 8u162 Early Access build 03 is available at :- http://jdk.java.net/8/*



*Feedback* - If you have suggestions or encounter bugs, please submit 
them using the usual Java SE bug-reporting channel.
Be sure to include complete version information from the output of the 
|java --version| command.


Regards,
Rory

[1] http://openjdk.java.net/projects/jdk/10/
[2] http://mail.openjdk.java.net/pipermail/jdk-dev/2017-November/89.html

--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland