Impact of six month releases (original) (raw)

Volker Simonis volker.simonis at gmail.com
Wed Nov 8 17:38:37 UTC 2017

On Mon, Nov 6, 2017 at 9:32 AM, Kim Jensen <kim at javadog.io> wrote:

Hi Volker,

Customers have so far been able to rely on Java, as a very innovative, stable, scalable and reliable platform - there is a reason why it is so widely adopted and used. However, with the release of Java 9 and the subsequent announcement of the new Release Cycles [1], many people were baffled. Earlier, we had at least a year to complete migration from one major version to the next. Sometimes the migration is not trivial, my best example is that JBoss only managed to ready for Java 8 one month before Java 7 the final Java 7 public update. Leaving us with very little time to test & push out the upgrades, as these all have to be coordinated with our customers internal patch & release cycles. Right now, we're in the situation that nobody knows how to deal with. Java 8 goes EOL in less than a year, Java 9 goes EOL in a few months. And the replacement has not even been released. Migrating to Java 9 is far from easy, we have so much code that doesn't work, and so many libraries which also fails. Right now, we cannot make any plans for the future - and the result will either be that the customers will run with outdated & insecure Java Versions or they'll go to different platform like .Net. It may be that in the future, the new LTS versions will work like a charm, but right now - with the new Release Cycle from Oracle - How can we upgrade ? Java 9 goes EOL in a few months and Java 8 in less than a year. It makes it impossible to plan, and this means that Java has moved from a rock solid foundation to a liability.

Well, that's not true. It is still rock solid. It just may be that for some use cases it moves from a free to a charged foundation :)

/Kim [1] http://www.oracle.com/technetwork/java/eol-135779.html Good judgment comes from experience; experience comes from bad judgment.

-------- Original Message -------- Subject: Re: Impact of six month releases Local Time: November 6, 2017 8:31 AM UTC Time: November 6, 2017 7:31 AM From: volker.simonis at gmail.com To: Stephen Colebourne <scolebourne at joda.org> jdk-dev at openjdk.java.net Hi Stephen, I fully agree with all the points you've raised. BUT the OpenJDK is not the binary Java distribution most people use (similar to that fact that few people use a vanilla Linux kernel). It wasn't even available until recently! The vast majority has always used the Oracle JDK or the JDK that comes with their Linux distribution (not to mention all the other commercial and free Java distributions which are available as well). All these binary distributions are downstream versions of the vanilla OpenJDK project and they can all freely choose their support time frame and downport policy. Again, as an analogy, just think about how Linux distros support old Linux kernels and enhance them with down ports from newer kernels independently of the main kernel development. My personal opinion is that we will eventually come to a similar model with Java. From my understanding the "new release cadence" step has always been at least as much about reorganizing the Java support business as it was about innovation. And it seems that others are now slowly realizing this as well ;) Regards, Volker Stephen Colebourne scolebourne at joda.org schrieb am Fr. 3. Nov. 2017 um 17:41: On 3 November 2017 at 09:14, Andrew Haley aph at redhat.com wrote: I think this is throwing the baby (Java's long standing backwards compatibility) out with the bathwater (frequent releases), but I'm happy to hear other opinions. I don't believe that such worries are necessarily justified. We need to be able to roll back mistakes. The Java tradition that nothing ever gets removed, no matter how much mistaken, holds back innovation. It does this because of a justified fear that if we make a mistake, we're stuck with it, so we have to be ultra-cautious. I think its more than that. Java's success is built on the broader ecosystem. The JDK itself is an enabler for that. Open source projects have to be able to produce jar files that work on multiple releases of the JDK. Things that prevent that are a big issue. In practical terms I'd argue that: LTS releases define the removal cycle. Code added in a non-LTS release (n) can be deprecated in the next non-LTS release (n+1) and removed in the release after that (n+2). This works because the code was never in an LTS release. However, code that was in the last LTS release cannot be removed until the release after the next LTS. eg. code present in 8 cannot be removed until 12 (as 11 is the first LTS where the deprecation is visible) eg. code added in 12 can be deprecated in 13 and removed in 14 as 12 and 13 are non-LTS There should be more than 2 security updates for each release. Without an overlap period, developers are forced to upgrade to the next release immediately it is GA. This does not reflect real-world software development practice. If the non-LTS releases are to be used in production they will need a bare minimum of 4 security updates (one year) to create a time window overlap with the next release. The javac --release flag should work for at least the last three LTS releases. A time-window of 10 years would also be about right. (Its a really convenient feature, and if possible I'd prefer it to never lose support for older versions). Stephen

More information about the jdk-dev mailing list