To Java 17 and beyond!

It’s already been 4 years since Oracle upturned Java’s slow release schedule (which includes 3 years between versions 7 and 8, and between versions 8 and 9), in favour of a release every 6 months. With each release, there is plenty of discussion about which new features have made it into the release and which features we’ll need to wait for until the next one. The release of Java 17 was no different in that regard.

Unlike the feature sets of some previous releases however (e.g. streams in Java 8, the module system in Java 9, or Record Classes in Java 14), this latest version doesn’t contain anything that is particularly world changing. For instance it includes a continuation of Vector API and Sealed Classes, both of which were already introduced in version 16 (as an incubator or a preview), as well as a release of Pattern matching for switch, and the removal or deprecation of some old language features. 

One notable difference is that version 17 is a Long Term Support (LTS) release. From the point of view of the features that are included, an LTS release is no different than any other (non-LTS) version. Even so, companies tend to go for LTS releases because they offer reduced risk due continuing bug fixes, and (at least the option of) paid-for support. As a result, most companies have not ventured beyond Java 11 (the most recent LTS version before Java 17).

More importantly though, despite Java 11 being the most recent LTS release, most companies have stuck with version 8 rather than move to Java 11, for a variety of reasons. This fact has hampered Java’s biggest libraries and frameworks, who do want to move along with the newer versions of Java, but also want to be usable for those who are unable (or unwilling) to move to a more recent Java version. And given the current market share of Java 8, that’s quite a big chunk.

There are however two things that may likely drive companies to adopt Java 17, even though they mostly gave Java 11 a pass. The first is that Oracle, in a surprising move, has announced that the Java 17 SDK will be ‘free of use’ (sort of, for a while). The second thing that may accelerate the move to Java 17 has to do with Spring. 

Spring is arguably the biggest name in the Java community. There is definitely no shortage of alternatives to the Spring framework, including mature frameworks such as Google Guice and Jakarta EE (formerly Java EE), and promising newcomers such as Quarkus and Micronaut. And yet, over the past 15 years, the Spring framework and its ecosystem have grown to dominate Java web development, to the extent that it’s often considered the go-to solution for Java enterprise applications.

Like many other big Java frameworks and libraries, Spring has necessarily kept its baseline at Java 8. In a somewhat surprising turn of events, Spring’s development team has announced that in version 6 of the framework (expected near the end of 2022), Java 17 will be used as the baseline. This means that Java applications that want to make use of Spring 6 have no choice but to use Java 17 (or higher) for their projects. Given the important role that Spring has had, and is continuing to have, in the Java ecosystem, I do not doubt that this will be the catalyst that makes companies move to Java 17, propelling the whole Java community along with it.

And that, I think, will mark the end of one Java era and the beginning of another.