End of life comes early for JDK 8
Changes are a-coming for Java. The switch from a feature-based schedule to a time-based release of the JDK has its pros and cons. But what does this mean for JDK 8? Simon Ritter explains how this new schedule means that developers may have to choose between stability, security, or cost.
This year is the year we see substantial changes in the world of the Java platform. As announced last year, we’re moving to time-based releases of the JDK, rather than a feature-based schedule. This is excellent news, as it means features can be integrated when ready and developers will get access to new features much faster than they ever have before. JDK 10 is scheduled for release in March, and we’re already into rampdown phase 2, so everything is progressing according to plan. The JSR for the specification is well underway and available for public review. There are even JDK Enhancement Proposals (JEPs) being targeted to JDK 11.
Everything appears to be great for Java.
Times are changing
However, there are more changes related to this new release cadence that will make themselves apparent this year, and these might not be quite so exciting.
For the last twenty-two and a half years, we’ve been used to Java being a platform that has three fundamental properties, explicitly related to how it is supported.
SEE MORE: “JDK 9 does not have big features for developers, it’s about changing the runtime with modularity”
- Stability: In the past, a new release of the JDK has added features, which, although thoroughly tested during development, need real-world production systems to identify any wrinkles that need ironing out. To enable users to continue with stable builds while testing the latest there has always been an overlap in updates.
If we look at the last few releases, starting with JDK 6, updates to JDK 5 continued to be published for nearly three years (two years and eleven months to be precise). With JDK 7, JDK 6 continued to have public updates for a year and nine months. JDK 7 then had thirteen months of public updates after the release of JDK 8.
- Security: The OpenJDK team, Oracle and Sun before them have always made the security of the platform as one of its highest priorities. Remember, when Java was first developed it was designed for a mobile device (the Star7 PDA).
One of the key design goals was being able to move code around the network and execute it securely.There are regular updates published for the JDK that include any patches for newly identified security issues. If you install updates as soon as they’re released, you’ll be as secure as you can be.
- Zero Cost: One of the greatest things about Java is that it’s always been a free platform, even before it was released as open-source in 2006.
There have been restrictions on where Java can be used without a license fee, but that has always been targeted at mobile and embedded applications; for desktop clients and enterprise servers the latest version has no cost.
One of the changes that has already started to happen for the JDK is the release of OpenJDK binaries that are provided under a GPLv2 license with classpath exception. This places no restrictions on how you can deploy the Java runtime.
However, changes to the way the JDK is developed and released will require you to think carefully about your plans for migrating your applications to new versions of Java.
With the new, time-based release cadence, the engineering effort of making updates available for numerous earlier releases would not be sustainable. To address the needs of two orthogonal groups of users (those who want new features quickly and those who want long-term stability), Oracle decided to switch to a Long Term Support (LTS) model. Specific JDK versions will be identified as LTS releases, meaning they will have updates for three years. All other, intermediate, releases will be termed Feature releases and only have updates for six months. To synchronize the new system, JDK 8 has been classified an LTS release. The next one will be JDK 11, to be released in September 2018.
The most significant change this new model includes is that there will no longer be any overlap for updates between releases. I’ve put that in bold and italics to make sure that this is clear.
Here’s a picture that shows the availability of updates for JDK releases up to JDK 19.
The implication of this change is that Java is still stable, secure and free but you must now choose two of those three qualities. When deploying Java in the future, you can’t have all three at the same time.
Let me explain this a bit more.
Suppose you are most concerned about security (as you should be) but don’t want to spend any money. To do this, you will need to switch to new versions of the JDK as soon as they are released. In cases where there is no support overlap (either for Feature or LTS releases) you must do this to have access to new security-related fixes. Unfortunately, with no overlap, you must switch to a JDK release that has not had time to be tested in real production environments, so you lose the stability you had.
Alternatively, you may favour stability and zero cost. Again, this is possible; all you do is continue to use the previous LTS version after a new one is released. You continue to have the stability you’re used to, need pay nothing, but will not get security patches, as they will no longer be available for that release.
Finally, if you want stability and security, it is not going to be free. You can continue to use the previous LTS release, but access to security and bug-fix patches will only be available through a commercial support contract.
SEE MORE: “Java 8 will satisfy us for a good few years until there’s something really big and important”
Azul has created our Zulu Enterprise branded OpenJDK binaries built from the project source, tested with the TCK/JCK and even analysed using tools we’ve designed to ensure that there is no contamination of the open-source through incorrect headers. We offer this as a free download for the latest version and with commercial support for those who want it.
We recently launched our new set of support options for Zulu that are designed to provide maximum flexibility for customers. We want users to be able to migrate to a new version of the JDK in a way that suits their business and customer needs.
To do this, we will be providing three lengths of support.
- Short-term support (STS): STS allows users the earliest access to new Java features with sufficient support to enable a smooth transition to a newer JDK release. For an STS release, Zulu Enterprise provides access to bug fixes, security updates, and other fixes as needed (“production support”) for twelve months plus six months additional support intended to advise and assist users to migrate to a newer JDK version (“extended support”). This provides an 18-month lifecycle.
- Medium-term support (MTS): MTS releases enable practical use in production environments of new capabilities available in feature releases without having to wait for the next LTS release. Azul designates one MTS release per year in the years between LTS releases and provides production support for 18 months past the GA date of the following LTS release. This ensures support overlap and a smooth transition path for production deployments. There are a further twelve months of extended support after production support finishes.
- Long-term Support (LTS): This will be provided for the same releases designated by the OpenJDK community as LTS, and provides 8-years of production support followed by a further two years of extended support.
Here’s another picture to help make this easier to understand.
If you’re currently using JDK 8 without a commercial support contract and are relying on public updates to keep your systems stable and secure, you need to start thinking about what is going to happen in September. Azul wants to help so get in touch with us if you need support.
Several aspects of the Java platform are changing this year, mostly for the better. Faster access to new features, tools like Flight Recorder and Mission Control being released under an open-source license and OpenJDK binaries released under the GPLv2 with classpath exception license. The reality is though that the generous free support for the Java platform that we’ve always been used to is going away.
Java is still stable, secure, and free. Which two of those three are most important for you and your users?