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