Beyond Java 8

This article is featured in the new DZone Guide to Java: New Developments & Features. Get your free copy for insightful articles, industry stats, and more!

If recent surveys are to be believed (including DZone readers, see page 3), most developers are still using Java 8 for the majority of their application. Before Java 8, uptake of a new version of Java was quite slow, particularly in enterprises where it can be difficult to get a new version of Java accepted for production. Java 8, with the introduction of lambda expressions and streams, was an appealing choice for many developers. The adoption of microservices, continuous delivery practices, and better-automated testing also makes it easier to use a new version of a language with far less risk than in the past.

So, given this, why is it that developers are "stuck" on Java 8, despite the fact that since Java 9, we now have two releases of Java a year? Java 12 is now the most recent version, and yet few people have made the leap to 9, 10, 11, or 12.

As you might expect, the answer is "it's complicated". There have been a number of different changes since Java 8 was released that may make organizations wary of upgrading.

Six Monthly Release Cadence

Since Java 9 (released September 2017), Oracle has been releasing a new JDK every six months, in March and September every year. In a continuous delivery world, it makes sense for our language to evolve much faster than every three years.

The new release cadence means that instead of getting huge,feature-packed releases dumped on us every few years, with the associated risks of such a big upgrade, we get much smaller releases on predictable dates. These releases have far fewer features of course, but there are several benefits to this model:

1. Easier to plan for. The predictable release cadence makes it easier not only for language developers to plan for, but also to plan our upgrades.

2. Higher quality. Frequent releases mean that if a feature isn't ready for this version of Java, it won't be long until the next release. This means far less pressure on language developers to rush to complete something, and, therefore, higher quality releases.

3. Steady supply of new features. Instead of three years of potential stagnation followed by a huge upgrade, we're getting regular updates of language features, garbage collector changes, and performance improvements.

The potential downside of moving to such a rapid release cadence is that many organizations simply can't keep up with upgrading every six months. This has been fully considered, not least of all because Oracle too will be impacted by this.

Long Term Support Releases

Oracle doesn't want to support every release for three (or more)years the way they used to support the previous releases. This would be a huge cost to them.

Figure 1: If Oracle supported every six-month release for three years, at some point in 2020 they'll be supporting six different versions of the language!

Instead, they've said one release every three years will be a Long Term Support release, which they will support for about three years. Java 8 was an LTS, the current LTS is Java 11, and presumably the next will be 17.

  

Figure 2: Oracle selects a release every three years to provide long term support and updates for, and the other releases only live for six months.

The intermediate releases, though, will not be supported once the next release is out. This means that Java 9 was replaced by Java 10, and when Java 11 was released it superseded Java 10.

Figure 3: When developers upgrade from Java 8, they generally upgrade all the way to Java 11.

This explains this pattern of adoption — generally, people will not be on Java 9 or 10. If they were using it at any stage, they should have moved on to at least Java 11.

With the combination of short-term releases that one should migrate from as soon as a new release is out and long-term releases that are supported for at least three years, there are now potentially two main approaches to upgrading:

1. Upgrade to every release as it comes out. This means adopting the latest version of Java every six months. The benefit is that you'll get new features as soon as they're available, but this approach will probably only suit those who are used to upgrading their technology stack this quickly.

2. Upgrade to just the long-term support releases. This is a more familiar cadence for us Java developers. This gives us the downside of a Big Bang release every three years, but we have more time to evaluate the risks of such an upgrade.

There's a potential middle ground here: use the LTS release in production, but make sure your application is running against each six-month release in CI. Doing this should minimize the risk of a big bang upgrade while maintaining the required stability in production.

Oracle doesn't want to support every release for three (or more) years the way they used to support the previous releases. This would be a huge cost to them.

License Changes

There is a caveat to these long-term support releases. Oracle's position is that if you want support and updates for three years, you should be prepared to pay for them. So, if you want to use an LTS and get updates for three years, you will need to pay Oracle for their commercial JDK.

However, Oracle recognizes that not everyone wants to do this and that many people want to work in an open-source friendly way, so they now have two versions of their JDK (both functionally the same) with two different licenses. They have their commercial JDK, which is free to use in development and testing but you need to pay to use it in production; and they have a zero-cost OpenJDK build. The latter has an open-source GPLv2+CPE license, but will only be updated within six months of this release lifespan.

In a continuous delivery world, it makes sense for our language to evolve much faster than every three years.

This is actually good from a competition point of view. Oracle has contributed everything from their JDK back to OpenJDK, even the features that used to be commercial features like Java Flight Recorder and Java Mission Control. So, any JDK built from OpenJDK, which is pretty much everyone's JDK, will have all the features you're used to using, and maybe even some you haven't used before.

There are plenty of other vendors offering JDKs. Many are free, some will be updated or supported for different lengths of time from the Oracle JDKs. This document lists these different options, separating those that are free to download and use from those that have a commercial model. If this all seems a little overwhelming, a good starting point is to download your OpenJDK build from AdoptOpenJDK. This JDK is compatible with the Oracle JDK, you can get builds for the major operating systems and platforms, you can choose from two different JVMs (Hotspot and OpenJ9), they have committed to providing builds for the LTS releases for at least 4 years, and you have the option to purchase commercial support.

Since this topic can be quite complex, I highly recommend reading the Java Is Still Free document produced by the Java Champions for more in-depth information.

In Summary

Lots of things have changed since Java 8's release: we get releases every six months; the licensing, update, and support models have changed; and where we get our JDK from may have changed. On top of that, there were language changes, including the major changes that went into Java 9.

While all of these changes may seem daunting, their goal is to provide high quality, frequent, and predictable updates to one of the most popular languages in the world, in a way that is sustainable to those who work on and support the language.

It's worth understanding the impact these changes may have on your application and organization, because working out how to embrace them will ultimately allow you to make use of the improvements that have already gone into the language since Java 8, and will continue to evolve and improve the language every six months.

This article is featured in the new DZone Guide to Java: New Developments & Features. Get your free copy for insightful articles, industry stats, and more!