X

Insights and updates on Java SE and OpenJDK from the Java Platform Group Product Management Team

  • September 17, 2018

End of Public Updates is a Process, not an Event

Donald Smith
Sr. Director of Product Management

And so, from hour to hour, we ripe and ripe.
And then, from hour to hour, we rot and rot;
And thereby hangs a tale.

Shakespeare

Successful software platforms and their surrounding ecosystems have a symbiotic relationship, with both positive and negative feedback cycles. As developers use a platform to build successful products that solve problems that could not as easily be solved before, the platform evolves over time to offer new features that make it a stronger fit for even newer use cases. At the same time, successful platforms adapt to changes in the technological environment around them, by deprecating and removing less-used legacy features.

This process is always in motion. As new versions of a platform are released, older ones are gradually ramped down so that platform providers can focus their efforts on the future, rather than on the past. 

The Java ecosystem has been going through this process successfully for decades, through ten major platform revisions. Strong backward compatibility over long periods protects investments made across the ecosystem. At the same time, some amount of adaptation is inevitable over time. The continued success of the platform, therefore, requires the bulk of the ecosystem to move on to the latest release, while protecting existing investments.

Sun Microsystems established the strategy of balancing these two goals by, on one hand, providing free public updates for a period of time while, on the other hand, offering commercial long-term support for users with different needs.  This strategy enables the bulk of the ecosystem to keep up with the release cadence for free, while providing additional security, performance and other updates under commercial terms to users who want to migrate from one platform release to the next on their own schedule, or not at all.

Every new beginning comes from some other beginning’s end

Java SE 8 was released on March 18th in 2014. By the time Oracle Java SE 8 reaches the end of public updates for  commercial users in January 2019, Oracle will have provided almost five years of continuous, free public updates.

With an Oracle Java SE Subscription, commercial users can continue to benefit from support and regular updates to Oracle Java SE 8, including enhancements and critical patches, for an even longer period of time. For example, the Java Web Start technology will continue to be commercially supported in Oracle Java SE 8 until at least March 2025.

Not all users of Oracle Java SE 8 use it commercially. Some use it to play games, or to run consumer productivity applications. Oracle will continue to provide free public updates of Oracle Java SE 8 for personal users until at least December 2020. During that time, personal users should contact their application providers and encourage them to migrate their applications to the latest version of Java, or else switch to alternative applications.

Upgrade to JDK 10

The shortest upgrade path from Oracle Java SE 8 leads to JDK 10. Instructions for application developers are available in the Oracle JDK 10 Migration Guide. Instructions for users migrating from Oracle JRockit are also available.

The latest Java release available as a download from Oracle at the time of writing is JDK 10.0.2. It’s at the security baseline, i.e., it contains fixes for security vulnerabilities described in the latest Oracle Critical Patch Update.

Upgrade to JDK 11

JDK 10 will reach its end of life in late September 2018. The next upgrade path from Oracle Java SE 8 leads to JDK 11. Oracle Java SE 11 is the next planned Long-Term Support (LTS) release and the first such release that’s part of the six-month cadence. Oracle Customers will, therefore, receive Oracle Premier Support and periodic update releases even after Java SE 12 is released. That makes Oracle Java SE 11 an attractive migration target for ISVs and other commercial users.

Since JDK 11 has not been released yet, the recommended course of action for developers targeting JDK 11 is to start working on the migration from Java SE 8 by making their applications run successfully on JDK 10. Due to the faster, semi-annual release cadence the number of changes between JDK 10 and JDK 11 is much smaller than between JDK 8 and JDK 10.

Once an application runs well on JDK 10, developers should test it with the JDK 11 Release Candidate builds in order to be ready to migrate to JDK 11 when it’s released later this month.

Upgrade to JDK 12

Developers who want to migrate an application straight from Oracle Java SE 8 to JDK 12 should follow the same migration model — begin with a larger migration effort to the latest release at the security baseline, i.e., JDK 10.0.2 at this time, and then, once the application works well, continue with an incremental migration to the latest available release of JDK 11.

Once the application works well on JDK 11, developers should begin testing it with JDK 12 Early Access builds. Oracle regularly publishes JDK 12 Early Access builds under the GNU General Public License, version 2, with the Classpath Exception. These builds allow developers to evaluate new JDK 12 features and test the impact of changes to existing features on their own applications.

Staying with OpenJDK 8 after January 2019

At this point, Oracle engineers have been leading and performing the majority of the maintenance work on OpenJDK 8 Updates in the OpenJDK Community for more than four and a half years. We’ll continue to do so until at least January 2019. After January 2019, the contributors from Oracle will likely refocus their efforts in the OpenJDK Community from OpenJDK 8 Updates onto other, current JDK releases, as we have in the past with OpenJDK 6, and OpenJDK 7 Updates.

As in the past, when a suitable party steps forward to continue to maintain OpenJDK 8 Updates after January 2019, we will discuss how to best enable such a transition in the OpenJDK Community.

Users interested in continuing to use OpenJDK 8 after Oracle engineers move on should therefore subscribe to the project’s mailing list by January 2019 and discuss their expectations and plans with the remaining contributors to better understand the scope of support available for OpenJDK 8 at that time.

 

Join the discussion

Comments ( 2 )
  • Christoph Straßer Wednesday, September 19, 2018
    I totaly understand your motivation to keep Java up-2-date. From a technical perspective there are some good reasons to do this.
    But there is one point i disagree. There are only a bit more than 3 months between the release of Java 11 (09/2018) and the end of public available Java 8 - Updates in january 2019.
    This put´s a lot of preasure to lot of people. Software-vendors have to update their java-based software within 3 months. And they have to release within 3 months. And customers have to update to this Java 11 - compatible version almost immediateliy. They have to take the risk to update to a possibly buggy software, which need´s some more time to run stable.
    From my perspective 6 or 12 months of free pubic updates for Java 8 would make life much easier und less riskier for people and companies within the java-ecosystem.
  • Donald Smith Wednesday, September 19, 2018
    Hi Christoph, thanks for your comment. I agree some practices will need to change, and it will take some effort. Also some tools are impacted more than others. But we've seen very positive changes already on a number of fronts, such as the ability of IDEs to support the release cadence on launch. This is likely because instead of having to code to 100's of changes every 3 years or so, they only need to adapt to a few changes every six months. It's much more manageable.

    More details here - https://blogs.oracle.com/java-platform-group/update-and-faq-on-the-java-se-release-cadence
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha