As work on Java SE 9 was winding down in early 2017, some contributors in the OpenJDK Community started wondering if there was a way to evolve the Java SE Platform and the JDK at a more rapid pace, so that new features could be delivered in timelier manner. A JCP working group was established to consider how the Java Community Process could accommodate such a change. After further discussion amongst key contributors a plan was proposed and, in parallel, Oracle announced plans for its commercial Java SE products [1].

In the few short months since then the OpenJDK Community has, with Oracle’s leadership, delivered Java SE 9, Java SE 10, Early Access builds of Java SE 11 as well as multiple coordinated scheduled security updates. The OpenJDK Vulnerability Group was formed. A small new language feature was added in Java SE 10 which shows the new cadence works not only for implementation, but also for specification work in the JCP.

That being said, the new cadence introduces new idioms and semantics to terms and processes we’ve been accustomed to for many years. Clearly, the benefits of a predictable release schedule of easily digestible new features are worth the effort to some of the largest projects in the ecosystem. We’ve seen this trend happening with other parts of the Java SE Ecosystem as well. For example, Eclipse, has long had an annual “release train,” and Wildfly is moving to a quarterly release model.

This blog entry will address some of the common questions that have been asked over the last several months.

Q1: Surely you can’t expect everyone to adopt major releases every six months?!

There are no “major releases” per se any more; that is now a legacy term. Instead there is a steady stream of “feature releases.” This is consistent with how many releases have been done in the past, except with a new take on versioning. For example, Java 8 launched in March 2014. 8u20, a feature release, was released almost six months later in August. 8u40, the next feature release, was released almost six months after that.

So yes, we expect an uptake of “feature releases” every six months, just as before.

Going from Java 9->10->11 is closer to going from 8->8u20->8u40 than from 7->8->9. It’s scary to see at first when you’re used to major releases about every three years and have a mental model of the huge impact of those major changes. The six-month cadence is not that. Later in the FAQ we’ll provide more specific proof of this.

Q2: If the new releases are basically the long standing six-month cadence, why rev the major release number each time? Why not just call it 9u20, 9u40, etc.?

By having streamlined some JCP processes, it’s now possible to introduce new class library, JVM and language features such as Local-Variable Type Inference in just six months, instead of having to wait years for a “major release.” Rather than releasing dozens of large changes to the specifications every couple of years, they can be more pragmatically introduced in a steady stream as soon as they are ready for adoption.

Q3: Spec changes sound dangerous and they’ll inhibit tools ecosystem from updating, right?

While some tools have struggled to move from 8->9, it’s been fantastic to see those who made that transition be able to go from 9->10 almost overnight.

When Java 10 was released, all the major IDEs had Java 10 support, including the new local-variable type inference feature within days. Popular projects such as Gradle and Lucene quickly added official support. Some popular Linux distributions such as Ubuntu and SUSE Linux Enterprise Server proactively adjusted to make the latest OpenJDK releases the default JRE/JDK on their platforms. Elasticsearch is planning to be compatible with both LTS and non-LTS releases as soon as possible to benefit from new features. These are just some of the examples of other projects and products keeping up with the six-month cadence.

The new cadence makes it more manageable and predictable for tools vendors, who will now have a steady stream of smaller updates. In addition, forward looking developers can explore new features in development such as minimal value types from OpenJDK Project Valhalla or the Z Garbage Collector from the OpenJDK Project ZGC using early access builds available under a familiar open source license.

Q4: Why would anyone update to version X when a new release X+1 is only six-months away?

The latest Oracle JDK builds and Oracle's OpenJDK builds are downloaded millions of times per month by developers. We have seen consistent growth of JDK downloads with each feature release, including 9 and 10. The latest releases of Java 10 are being downloaded at a much higher rate than those of Java 7 and Java 8 were. For example, JDK 10 downloads as of this writing exceed those of JDK 8 updates by a factor of five.

The strong uptake of the new release cadence is impressive. It is very encouraging to see popular IDEs and other tool vendors adopt and make Java 10 support available quickly.

Q5: I’m still not convinced. Java 9 was a challenge to adopt, so that means 10 and 11 will be, too.

Many Java SE developers and user have historically waited for a couple of updates before adopting a new “major version.” This could be expected when there were dozens of major new spec-changing features in a “major” release, but won’t be the case going forward with six-month releases. This has not been the case since Java SE 9.

For example, the Java SE 9 release incorporated approximately 19,000 source code changes on top of Java SE 8. There were only 2,700 such changes between Java 9 and Java 10 – approximately the same as between Java 8 and Java 8u40. So while Java SE 9 was a “major” upgrade compared to Java SE 8, we have already seen that Java SE 10 is a simple feature update to Java SE 9.

Q6: How can I be confident that the X+1 release transition will be smooth? How much time is there to transition?

EA Builds are even easier than before to download and try, including Oracle’s own OpenJDK builds. We encourage developers to use Oracle’s OpenJDK EA builds in their build-test systems so any issues can be caught early.

There are three months from the final update of a feature release and the security update of the next feature release. We strongly recommend transitioning during this time. There is approximately one month from a new feature release and the next scheduled security update. For example, Java 9.0.4 was released in January 2018, Java 10.0.0 in March 2018 and 10.0.1 in April 2018. After the Java 10.0.1 release, we do not recommend using Java 9.0.4 or Java 10.0.0. You don’t have to wait for one month, or even three months to start testing, though - Early Access builds of JDK 10 have been published regularly starting in November 2017, more than six months before the 10.0.1 update release.

This is consistent with historical feature releases where there have been 4-6 weeks between feature releases and a subsequent security update. For example, 8u40 was released in early March, 2015 and the subsequent scheduled security update 8u45 was released on April 14th 2014.

Q7: Ok, but I don’t want new features. I have a system in production and just want stability, performance and security updates only. What do I do?

At Oracle, our intent is to designate releases every three years as “Long Term Support” (LTS) releases starting with Java SE 11 in September 2018. So while Java SE 9 has reached its End of Life with the release of Java 10, and Java 10 will do the same with the release of Java 11, Java 11 will have commercial support from Oracle available for at least eight additional years.

As has happened for almost a decade with Java 6 and Java 7 (and likely Java 8 in 2019), once Oracle stops contributing our source code changes to a particular release series in OpenJDK, so that we can focus on the needs of our customers, other qualified contributors in the OpenJDK Community may step in to continue to maintain the release series. They do so in accordance with OpenJDK Community standards for as long as they choose, backporting the relevant changes from later releases still maintained by Oracle and others. For example, for JDK 6, Sun established the project in 2008, and Oracle continued to maintain it until 2013. Other maintainers then continued working on the project by backporting updates from later releases.

Oracle supports such transitions in the OpenJDK Community by providing an established process for them to take place within the JDK Updates Project, as well as assistance to new maintainers to settle in their new roles, and last but not least, the Vulnerability Group.

Q8: What’s happening with Java SE 8?

Java SE 8 is the end of the legacy versioning and release cadence model; Java 9 was the new beginning.

For the Oracle JDK, Java 8 is going through the exact same transition processes as with Java 7 and Java 6, with a few exceptions. First, to give additional time to get accustomed to the new release model, Oracle extended the public updates of its Oracle JDK to January 2019 for commercial production use, and at least the end of 2020 for individual desktop use. Second, we announced our efforts to make the Oracle JDK interchangeable with Oracle’s OpenJDK builds for those who want to move up to the next releases, as they did for Java 6->7 and Java 7->8. If you haven’t already done so, we’d suggest moving to 10 and getting on the new release train. Finally, Oracle has posted more information on the roadmap for the Java Client (including Applets and Web Start).

On the OpenJDK front, Oracle plans to continue to lead and contribute to the JDK 8 Updates project until January 2019, before which a call for new maintainers will be made (as has been practice for over a decade, see previous Q for more details).

Q9: I’m an Oracle Customer, how am I affected?

You’re covered for your use of Java SE within an Oracle product having a Java SE dependency. Find out more details via this My Oracle Support note.

Edited May 4th, 2018 . Added numbers to questions and added reference to roadmap for Java Applets and Web Start in Q8.

Footnotes:

[1] - ;tldr for the plan that Oracle has announced for its binaries and builds – (a) move all previously closed source bits from the Oracle JDK into OpenJDK (b) publish OpenJDK binaries under the GPLv2+CPE and (c) ensure a smooth transition such that Oracle JDK and OpenJDK binaries are interchangeable.