Impact of six month releases
kim at javadog.io
Mon Nov 6 08:32:43 UTC 2017
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 , 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.
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
> Stephen Colebourne scolebourne at joda.org schrieb am Fr. 3. Nov. 2017 um
>> 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).
More information about the jdk-dev