Re: Impact of the new Java release policy on Debian
Le 30/11/2017 à 12:31, dalibor topic a écrit :
> a few comments on the thread:
Thanks a lot for the input!
> * For JDK 9, I have posted
> 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:
"Remove deprecated pre-1.2 SecurityManager methods and fields"
As long as the SecurityManager isn't removed...
"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