Re: Impact of the new Java release policy on Debian

[dalibor topic]

On 30.11.2017 13:43, Emmanuel Bourg wrote:

Do you know if Oracle intends to keep contributing Java LTS updates to
OpenJDK beyond the 6 months window (i.e. after March 2019 for Java 11)?


In the past, Oracle's plans for the duration of its contributions to an 
OpenJDK update release series have been publicized only once the update 
release has been well underway. Since work on JDK 11, much less its 
updates, hasn't begun yet, I unfortunately don't have anything to share 
so far.

"Remove deprecated pre-1.2 SecurityManager methods and fields"

As long as the SecurityManager isn't removed...


There is no plan to do so in the near or middle term, per 
http://mail.openjdk.java.net/pipermail/security-dev/2017-November/016526.html



We use these flags in jarwrapper to detect the endianness of the JVM and
initialize the java.library.path property. We'll have to use another
detection mechanism (like running an actual class that dumps the
sun.arch.data.model property).


You could look into the 'release' file instead, per 
https://bugs.openjdk.java.net/browse/JDK-8179600 it also contains 
information on the $ARCH the JDK was compiled for.


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: Impact of the new Java release policy on Debian

[Thorsten Glaser]

On Thu, 30 Nov 2017, Emmanuel Bourg wrote:

> Le 30/11/2017 à 14:31, Thorsten Glaser a écrit :
> 
> > Eek, that would break most of Debian’s stability promises.
> > People would lynch you.
> 
> I know :) That's why I mentioned "near perfect backward compatibility"
> as a prerequisite.

Well, it’s not just that. People often use the interpreters
shipped in Debian to also run software itself not packaged
in Debian.

While mksh (the shell I develop) does not quite have the
amount of programs written in it (although the installed
base is getting closer to Java) we’re somewhat sitting in
the same boat: many Java applications cannot, currently,
realistically be packaged for Debian because too many
dependencies aren’t for people to even try within any
given timeframe, and shell scripts or programs aren’t
often packaged either.

So, I’d never include a breaking change in a stable upload
of mksh, and Java is even more fragile (despite Oracle Java
being “the same as” OpenJDK recently, stuff still occasio‐
nally behaves different, etc.), so I’d expect that the JDK
shipped with stable doesn’t change, only receive security
and critical bugfixes.

Note I’m explicitly *not* distinguishing between JDK and
JRE because my employer deals in Java, and as such, many
people and headless systems (like Jenkins) have the JDK
installed while other systems (most, but not all, servers)
only have JRE-headless, and we’d like to achieve version
equality (which is also why I spoke out against having
version skew between JDK and JRE in buster).

I’m really surprised Oracle’s going to pull a Mozilla and
try to push out new Java major(!) versions every few months
now, when traditionally this has been extremely slow-moving.
This sounds extremely disconnected from the Real Life.

For comparison, we have a hard time getting some customers
to upgrade from Java 7 to 8, and I heard one or two might
still be using Java 6 in 2017. I’ve actually been actively
progressive in basically demanding that our developers fix
stuff for Java 8 *because* of Debian being so progressive
as to ship it ;-)

Just my personal insight, but with several PoVs (I maintain
a comparable-in-a-manner interpreter, I package the occasio‐
nal Java stuff for Debian when necessary, I use Debian’s JDK
and Maven and Jenkins for $dayjob, and the latter has somehow
gotten me into not just trying to operate but also patch Java
code, plus supporting customers in running and debugging it,
and I’ve got a good understanding of how Debian operates, and
stand behind it).

bye,
//mirabilos
PS: Occasionally, my employer might be hiring; look at the
.signature if interested, I don’t even know if they do
at the moment.
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Re: Impact of the new Java release policy on Debian

[Emmanuel Bourg]

Le 30/11/2017 à 14:31, Thorsten Glaser a écrit :

> Eek, that would break most of Debian’s stability promises.
> People would lynch you.

I know :) That's why I mentioned "near perfect backward compatibility"
as a prerequisite.

Emmanuel Bourg

Re: Impact of the new Java release policy on Debian

[Thorsten Glaser]

On Thu, 30 Nov 2017, Emmanuel Bourg wrote:

> > major (LTS or other) OpenJDK release during the lifetime of stable
> > release, maybe even on a regular cadence as a 'rolling' default.
> 
> A rolling default JRE might be interesting, that would reduce the number
> of JDKs maintained (assuming unstable, stable and oldstable are all
> aligned on the same release at some point in time) and provide more
> recent updates to our users. But this requires a near perfect backward
> compatibility of the JDK APIs and tools, because we can't push an update
> that would break applications in production. I'm under the impression

Eek, that would break most of Debian’s stability promises.
People would lynch you.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Re: Impact of the new Java release policy on Debian

[Emmanuel Bourg]

Le 30/11/2017 à 12:31, dalibor topic a écrit :
> Hi,
> 
> a few comments on the thread:

Thanks a lot for the input!


> * For JDK 9, I have posted
> http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2017-November/24.html
> regarding Oracle's planned contributions. In short, Oracle plans to end
> contributing JDK 9 Updates to OpenJDK with the end of public updates of
> JDK 9 in March 2018.

Do you know if Oracle intends to keep contributing Java LTS updates to
OpenJDK beyond the 6 months window (i.e. after March 2019 for Java 11)?


> My suggestion, in light of the current level of Debian OpenJDK
> packagers' involvement in upstream OpenJDK 8 & 9 update maintenance,
> would be to explore the alternative to fixing a specific default-jdk for
> three (or more) years, and instead to consider updating it to a new
> major (LTS or other) OpenJDK release during the lifetime of stable
> release, maybe even on a regular cadence as a 'rolling' default.

A rolling default JRE might be interesting, that would reduce the number
of JDKs maintained (assuming unstable, stable and oldstable are all
aligned on the same release at some point in time) and provide more
recent updates to our users. But this requires a near perfect backward
compatibility of the JDK APIs and tools, because we can't push an update
that would break applications in production. I'm under the impression
this isn't going to happen until the old stuff deprecation/removal
frenzy is over, maybe in a few years.

There is another aspect worth considering though. Even if the non-LTS
releases are intended to be stable and production-ready, I don't think
they'll be widely adopted because they imply a forced 6 months upgrade
and testing cycle that many can't afford. Thus the LTS releases are more
likely to be the "normal" Java that companies will use, and they'll
logically expect Debian stable releases to provide these versions rather
than the short lived ones.


> There is about a dozen changes so far from the list that signify removed
> deprecated or internal APIs and tools in JDK 10:
> 
> https://bugs.openjdk.java.net/browse/JDK-8189750

"Remove deprecated pre-1.2 SecurityManager methods and fields"

As long as the SecurityManager isn't removed...

> https://bugs.openjdk.java.net/browse/JDK-8180947

"Remove the launchers data model flags -d32/-d64"

We use these flags in jarwrapper to detect the endianness of the JVM and
initialize the java.library.path property. We'll have to use another
detection mechanism (like running an actual class that dumps the
sun.arch.data.model property).

http://sources.debian.net/src/javatools/0.61/jarwrapper/?hl=46#L46

Emmanuel Bourg

Re: Impact of the new Java release policy on Debian

[Matthias Klose]

On 24.11.2017 11:05, Emmanuel Bourg wrote:
> Hi all,
> 
> Oracle has recently announced a new release policy for Java [1][2], to
> sum it up:
> - new major Java revisions will now be released every 6 months
> - there will be non-LTS releases supported for 6 months, and LTS
> releases supported 5+ years
> - LTS releases will be cut every 3 years
> - Java 9 is *not* a LTS release, the next one will be Java 11
> (previously named Java 18.9), to be released in September 2018
> 
> This is of course the policy for Oracle Java, not OpenJDK. It's not
> clear at this point if other players like Red Hat intend to support
> non-LTS OpenJDK releases longer than 6 months.

yes, and I think there is the wrong conclusion that *OpenJDK* LTS releases will
get five years of support.  What I am reading is that OpenJDK source releases
will be made for 18 months (three updates), not more, and that the sources for
those Oracle releases are not made public.

> Assuming that Debian will stick to the LTS releases as defined by Oracle
> I can see the following consequences:
> - openjdk-9 will not be part of Buster, and we should aim for openjdk-11
> instead.
> - If the freeze for buster starts in December 2018, we'll barely have 2
> months to complete the transition. Ideally we should start testing
> sooner with pre-release builds.
> - If we keep openjdk-8 as the default JRE until openjdk-11 is ready we
> may not catch runtime issues with the latest JREs and fix them in time
> for the freeze. This means we should probably change the default JRE as
> soon as possible to openjdk-9/10 but keep openjdk-8 in the archive as a
> possible fallback if we can't complete the transition to openjdk-11
> before the freeze.
> - After Java 11 the next LTS would be Java 17 to be released in
> September 2021, probably after the Debian 11 release which would thus
> ship the same JRE than Debian 10.

having an unsupported OpenJDK version in a release which is only used for
building packages could be an option, yes.

Matthias

Re: Impact of the new Java release policy on Debian

[Markus Koschany]

Am 27.11.2017 um 13:08 schrieb Thorsten Glaser:
> On Sun, 26 Nov 2017, Markus Koschany wrote:
> 
>> released in time before the freeze, we could try to make OpenJDK 11 the
>> default JRE but keep OpenJDK 8 as the default JDK. I think it is
> 
> Eek, having more than one Java version on a system at a
> given time invites trouble. (Yes, I know it works within
> Debian, but…)
> 
> bye,
> //mirabilos

The alternative mechanism works quite well but the idea is that you only
have to install OpenJDK 11 to run all your Java applications. You would
only need OpenJDK 8 if you want to make changes to your packages and
rebuild them. Of course the ideal solution would be to fix all FTBFS
bugs with OpenJDK 11 in time so that we can ship only one JDK/JRE!

Cheers,

Markus



signature.asc
Description: OpenPGP digital signature

Re: Impact of the new Java release policy on Debian

[Thorsten Glaser]

On Sun, 26 Nov 2017, Markus Koschany wrote:

> released in time before the freeze, we could try to make OpenJDK 11 the
> default JRE but keep OpenJDK 8 as the default JDK. I think it is

Eek, having more than one Java version on a system at a
given time invites trouble. (Yes, I know it works within
Debian, but…)

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Re: Impact of the new Java release policy on Debian

[Markus Koschany]

Am 24.11.2017 um 11:05 schrieb Emmanuel Bourg:
> Hi all,
> 
> Oracle has recently announced a new release policy for Java [1][2], to
> sum it up:

[...]

Well, like you said, provided that OpenJDK 11 is also a LTS version and
released in time before the freeze, we could try to make OpenJDK 11 the
default JRE but keep OpenJDK 8 as the default JDK. I think it is
unrealistic that we can fix all build failures in two months. We would
have a similar situation as in Wheezy again, two Java environments but
only one (OpenJDK 11) is supported with security updates during the LTS
cycle. The other one (OpenJDK 8) is intended for development and
rebuilding packages. I wouldn't mind if java-common would switch the
default JRE to OpenJDK 9 right now but we should keep OpenJDK 8 as the
default JDK.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature