Partner – Microsoft – NPI (cat=Java)
announcement - icon

Microsoft JDConf 2024 conference is getting closer, on March 27th and 28th. Simply put, it's a free virtual event to learn about the newest developments in Java, Cloud, and AI.

Josh Long and Mark Heckler are kicking things off in the keynote, so it's definitely going to be both highly useful and quite practical.

This year’s theme is focused on developer productivity and how these technologies transform how we work, build, integrate, and modernize applications.

For the full conference agenda and speaker lineup, you can explore JDConf.com:

>> RSVP Now

1. Introduction

In this article, we’ll discuss the new time-based releases of Java and the impact on all types of developers.

Changes to the release schedule include updating the feature delivery and support levels for versions of Java. Overall, these changes are distinctly different from the Java that has been supported by Oracle since 2010.

2. Why Six-Month Releases?

For those of us used to Java’s historically slow release cadence, this is a pretty significant departure. Why such a dramatic change?

Originally, Java defined its major releases around the introduction of large features. This had a tendency to create delays, like those we all experienced with Java 8 and 9. It also slowed language innovation while other languages with tighter feedback cycles evolved.

Simply put, shorter release periods lead to smaller, more manageable steps forward. And smaller features are easier to adopt.

Such a pattern pairs well in current conditions and allows JDK development to work in agile methodologies akin to the community it supports. Also, it makes Java more competitive with runtimes like NodeJS and Python.

Of course, the slower pace also has its benefits, and so the six-month release cycle also plays a role in a larger Long Term Support framework, which we take a look at in Section 4.

3. Version Number Change

A mechanical aspect of this change is a new version-number scheme.

3.1. JEP 223 Version-String Scheme

We’re all familiar with the old one, codified in JEP 223. This scheme made version numbers incremental and relayed extra information.

   Actual                    Hypothetical
Release Type           long               short
------------           ------------------------ 
Security 2013/06       1.7.0_25-b15       7u25
Minor    2013/09       1.7.0_40-b43       7u40
Security 2013/10       1.7.0_45-b18       7u45
Security 2014/01       1.7.0_51-b13       7u51
Minor    2014/05       1.7.0_60-b19       7u60

If we run java -version on a JVM for version 8 or older, we’ll see something like:

>java -version
java version "1.6.0_27"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.6.0_27-b07)
Java HotSpot(TM) Client VM (build 1.6.0_27-b13, mixed mode, sharing)

In this case, we might guess this is for Java 6, which is correct, and the 27th update, which is wrong. The numbering scheme isn’t as intuitive as it appears.

Minor releases were multiples of 10, and security releases filled everything else. Typically, we would see the short string appended onto our local installations, such as JDK 1.8u174. The next release may be JDK 1.8u180, which would be a minor release with new fixes.

3.2. New Version-String Scheme

The new version-string scheme will “recast version numbers to encode not compatibility and significance but, rather, the passage of time, in terms of release cycles,according to Mark Reinhold in the JEP.

Let’s take a look at some:

9.0.4
11.0.2
10.0.1

At a quick glance this appears to be semantic versioning; however, this is not the case. 

With semantic versioning, the typical structure is $MAJOR.$MINOR.$PATCH, but Java’s new version structure is:

$FEATURE.$INTERIM.$UPDATE.$PATCH

$FEATURE is what we might think of as the major version, but will increment every six months regardless of compatibility guarantees. And $PATCH is for maintenance releases. But, this is where the similarities stop.

First, $INTERIM is a placeholder, reserved by Oracle for future needs. For the time being, it will always be zero.

And second, $UPDATE is time-based like $FEATURE, updating monthly after the latest feature release.

And finally, trailing zeros are truncated.

This means that 11 is the release number for Java 11, released in September 2018, 11.0.1 is its first monthly update release in October, and 11.0.1.3 would be a hypothetical third patch release from October’s version.

4. Multiple Version Distributions

Next, let’s look at how to pick the right version.

4.1. Stability

Simply put, Java now has a fast channel, every six months, and a slow channel, every three years. Each third-year release is called an LTS release.

On the fast channel, the language releases features in incubation. These language features stabilize in the LTS release.

So, for companies that can embrace volatility in exchange for using new features, they can use the fast channel. For enterprises that appreciate stability and can wait to upgrade, they can upgrade at each LTS release.

Experimentation with JDK versions enables developers to find the best fit.

4.2. Support

There’s also, of course, the matter of support. Now that Java 8 support has sunset, what do we do?

And as discussed earlier, the answer comes in LTS versions, Java 11 being the most recent LTS release and 17 being the next. Updates will be available and supported by vendors such as Oracle and Azul.

If we can trust the support of the community, then Redhat, IBM, and others have stated their support for applying bug fixes for OpenJDK. Also, the AdoptOpenJDK project provides pre-built binaries for OpenJDK.

4.3. Licensing

One area of confusion for some is the difference between OpenJDK and Oracle JDK.

Actually, they are nearly identical, differing only in which bug fixes and security patches have been picked up, according to Brian Goetz.

OpenJDK acts as the source of most derived JDKs and remains free. Starting with Java 11, Oracle will charge commercial license fees for the Oracle JDK with additional support and services included.

4.4. Fragmentation

With more frequent releases, fragmentation may become an issue. Hypothetically, everyone could be running on different versions of Java with different features even more so than now.

Of course, containerization could help address this. From Docker and CoreOS to Red Hat’s OpenShift, containerization provides the needed isolation and no longer forces one installation location for Java to be used across the server.

5. Conclusion

In conclusion, we can expect a lot more from the Java team at Oracle with a regular release of Java every six months. As a Java developer, the prospect of new language features every six months is exciting.

Let’s keep in mind some of the implications as we decide what our upgrade channel is if we need support and licensing, and how to cope with fragmentation.

Course – LS (cat=Java)

Get started with Spring and Spring Boot, through the Learn Spring course:

>> CHECK OUT THE COURSE
res – REST with Spring (eBook) (everywhere)
Comments are closed on this article!