Impact of six month releases

[Volker Simonis]

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
>
>