Java 17 was recently publicly released by Oracle on schedule (Sept 2021). This is a significant and highly anticipated new release for Java engineering teams around the world, for several reasons. I predict it will see mass adoption and become the dominant version of Java used by enterprises over the next couple of years. Read on to find out more, including learning about the major new language features in Java 17 that engineering teams can benefit from, including code examples.
1) A New Long Term Support (LTS) Release!
Java 17 has been designated a long term support (LTS) release – the first one since Java 11 was released 3 years ago in Sept 2018.
Since LTS releases were first introduced 4 years ago in Sept 2017, along with the switch to regular, time-based releases of Java, many Java engineering teams I talk to have adopted the policy of only adopting LTS releases in production, and not the interim Java releases. This is mostly driven by the need to be able to obtain extended maintenance updates and support for Java releases for longer than 6 month after their release. (I’ve previously discussed this topic in more detail when writing about past Java releases e.g. for Java 9 (section 6) So, should you upgrade?) and Java 10 (section ‘Support considerations)).
LTS releases provide extended, free public updates (maintenance and security fixes) and commercial support, typically for more than 5 years. For Java 17, following its release in Sept 2021, we can look forward to and benefit from these free public updates for at least 6 years to Sept 2027 (depending on your chosen JDK vendor / provider); as well as a broad choice of commercial support for up to 8 years to Sept 2029. In both cases this is now 3 years longer than for Java 11.
In addition, third-party vendors of software are aligning support and maintenance plans for their own products and services with Java LTS releases, because they know that’s where their customers will be heading. For example, the Spring team have recently announced that the next major version of Spring (6.x) due in 2022 Q3 or Q4, will have a minimum requirement of Java 17.
2) New Language Features
While extended maintenance and commercial support is important it’s not the only thing that will drive adoption of Java 17. Many new features have been added to the language since Java 11 which have the benefits of improving programmer productivity, reducing the cost of code maintenance, and assisting with troubleshooting. The majority of these features were already available in previous, interim non-LTS Java releases 12 to 16. However, for many businesses that are following the aforementioned policy of only adopting LTS releases, Java 17 will be the first opportunity for their production applications to benefit from these engineering improvements that have been made to the language and JVM (covered separately below) in the intervening 3 years since Java 11.
Below is a list of the most significant new language features that were finalised in JDK releases 12 to JDK 17 inclusive. To better understand each of the features and how they’re used, I’ve created an executable set of code examples. You can find these on GitHub at https://github.com/neiljbrown/java17-examples.
Switch Expressions (JDK 14, March 2020)
Switch expressions provide an improved version of the switch statement which reduces boilerplates, avoids common errors, and supports assigning the result of the switch logic to a final local variable. (Switch expressions will also support pattern matching of switch variables in the future). For more details see
Text Blocks (JDK 15, Sept 2020)
Text Blocks provide a new way to declare a multi-line string (aka text block), that is simpler, and easier to read and maintain, by removing the need for concatenation, escaping of double quotes, and the need to specify new lines explicitly. For more details see
Pattern Matching for instanceof (JDK 16, March 2021)
Pattern Matching for instanceof enhances the instanceof operator to reduce boilerplate by removing the need to declare a separate variable of the matched type and cast the result. For more details see
Records (JDK 16, March 2021)
Adds a new type of Java class that is designed to make it easier to declare immutable data-structures in Java, with less code than has traditionally been necessary, and in so doing also make the code easier to read, interpret and maintain. For more details see
Sealed Classes (JDK 17, Sept 2021)
Sealed Classes provide a new way for developers to restrict which classes can extend or implement a class or interface they author, without constraining access / usage of them. For more details see:
It would have been nice to see one or two more language features make it into this new LTS release, given how long we’ve waited for it, but they just weren’t ready yet.
Of the above, Records will be the most widely used feature and deliver the biggest benefit, in terms of the gain in conciseness, readability and immutability of code.
3) Java Virtual Machine Enhancements
The benefit of upgrading from Java 11 to Java 17 isn’t just limited to a new LTS release, and new language features. Our production workloads will also benefit from enhancements and a raft of improvements that have been made to the Java Virtual Machine (JVM). My personal highlights are outlined below.
3.1) New Platforms for Enhanced Security & Performance
Upgrading to Java 17 adds official support for using Java on new platforms and operating systems.
Alpine Linux – Java 16+ includes the changes required to enable Java to reliably run on the Alpine Linux. Alpine Linux is a slimmed down Linux distribution that’s designed to offer increased security by having a smaller attack surface area. This facilitates building containerised services that have fewer exploitable vulnerabilities, that will also be faster to deploy and scale-out. For more details see JEP 386: Alpine Linux Port.
Apple macOS/AArch64 Port– Apple are transitioning their devices from Intel x64 to Apple’s own ARM 64-bit (AArch64) CPUs. Java 17 supports running Java on this new hardware platform without relying on macOS translation. This will simplify and improve the performance of Java apps running on Apple devices, whether in production environments, or developers using new Macbooks. For more details see JEP 391: macOS/AArch64 Port.
3.2) Enhanced Production Profiling
The Java Flight Recorder (JFR) is an existing low-overhead profiling tool included in the JVM that’s designed and built by Oracle engineers to support troubleshooting, monitoring and profiling the JVM and apps, whilst running in production, with minimal overhead. I previously wrote about how this tool was previously a premium feature only available in the Oracle JDK, but from Java 11 onwards was included in all JDK distributions, and has been available to use for free. Since then, in Java 14, the JFR has been enhanced to support real time monitoring by allowing tools to subscribe to events it publishes This makes it possible to process profiling results more quickly, rather than having to collect all of the performance data to a file for a period of execution, and analyse it separately, offline. For more details of this enhancement see JEP 349: FR Event Streaming.
3.3) Performance Improvements
As is the case on every new release of Java, the JVM has been further optimised to run workloads faster with fewer resources, for example based on improvements to garbage collectors. So, this Java upgrade also has the potential to reduce operating costs of your Java applications. Of course, you’ll want to first run some performance tests on your workloads prior to cutting over to Java 17 to check you’re not experiencing any unexpected degradations in performance after the upgrade.
4) Java Standard Library APIs
From a developer’s perspective there haven’t been many major changes to the Java SE (‘core’) library APIs between Java 11 and Java 17.
One noteworthy change is a new algorithm for implementing digital signatures that’s intended to provide additional security and better performance. For more details see JEP 339: Edwards-Curve Digital Signature Algorithm.
5) Java Tooling
In addition to the JVM tooling already mentioned above (such as the Java Flight Recorder), upgrading from Java 11 to 17 also includes a new standalone tool.
JPackage (added in Java 16) supports creating installation packages for Java applications (JARs) using a native package format for either Windows (MSI and EXE), macOS (PKG and DMG) and Linux (DEB and RPM). The created installation packages allow you to install and run your Java app without requiring Java to be installed on the target machine. For an example of how to use JPackage see the video The Packaging Tool aka `jpackage` – JEP Café #4. For more details see JEP 392: Packaging Tool
6) Planning Your Upgrade
6.1) Platform Support / Compatibility
If you’re deploying your apps to a 3rd party platform provider, such as a public Cloud provider’s PaaS, or a FaaS platform, then your plan / schedule for upgrading may be dictated by the availability of Java 17 on those platforms. However, if your services/apps either run on premise, or are containerised, then you’re typically free to choose your own schedule for upgrading to Java 17.
6.2) Third Party Software Support / Compatibility
Before committing to a date for upgrading your apps to Java 17 in production, first check when the providers of all your dev tools (build, IDE, static code analysis) and third party library dependencies have confirmed their software is compatible. This will inevitably lead to there being a lag while these projects have time to test their software for compatibility and release new versions containing any necessary updates. However, if you’ve stuck to using popular, mainstream tools and dependencies, then you shouldn’t have to wait too long. For example –
Toolchain
IDE – JetBrains’ IntelliJ IDEA release 2021.2+ already has (code completion and compilation) support for all of JDK 17 language features (see IntelliJ Online Docs > Version 2021.2 > Project Configuration > SDKs > Supported Java versions and features (26/07/21)).
Build Tools – At the time of writing (Oct 2021) the latest available GA version of Gradle (7.1.2) does not officially support running on Java 17, and as of yet there is no announced date for when Java 17 support will be available. However, when producing my Java 17 code examples I found that Gradle 7.1.2 did run on Java 17, and I haven’t yet discovered any incompatibilities. If this is an issue for you in the short term, then an alternative is to use Gradle’s Toolchain support for using a different version of the JDK to compile and run your app then the one used to launch/run Gradle. For the latest announcements of Gradle support for Java 17 see the Gradle docs – Compatibility Notes and Release Notes.
Spring Framework
The Spring team already has Java 17 support in place.
The current 5.3.x line of the core Spring framework already supported JDK 8 and JDK 11. From 5.3.10, this support has been extended to additionally include JDK 17. This support for the past three LTS releases is significant as it allows you to separate the upgrade of Spring, and perform it before upgrading to Java 17.
On 23/09/21, the Spring team also announced the GA release of Boot 2.5.5 which supports JDK 17.
6.3) Upgrade Strategy
Java’s strong commitment to backwards compatibility means that for some applications it may be possible to take existing releases compiled using your current version of Java (e.g. previous LTS release 8 or 11) and run them using Java 17, without requiring any changes to your application or dependencies. This will also depend on whether the existing versions of third-party software you’re using at runtime, such as application frameworks, are compatible with running on Java 17 already, without requiring an upgrade, and whether you’re willing (based on your own inhouse testing) to use them in conjunction with Java 17 even if that’s not officially supported by the vendor.
This is worth checking, because if it is the case, it gives you the option of splitting the upgrade into two phases and reducing some of the risk. In phase 1 you can just upgrade the runtime version of Java in production. This will deliver many of the new features and benefits described above, except the new language features. And if there is an unexpected issue with Java 17 in production (which for some reason went undetected during your testing) then you can simply switch back to the previous version of Java, without needing to redeploy your app(s). Once this has bedded in, as a second phase you can then adopt new language features in subsequent releases of your app(s), safe in the knowledge that there will be no Java 17 specific issues.
7) Summary
In this post I covered
- The significance of Java 17 being a Long Term Support (LTS) release, and it therefore being a good release for businesses to target, strategically.
- The major new features and enhancements that are available on upgrading from Java 11 (the previous LTS release) to Java 17, including
- Several major new language features. These will be of interest and value to developers, to help increase their productivity and write code that’s easier to read and maintain;
- A few significant enhancements and performance improvements to the JVM, including support for new platforms and operating systems.
- A full list of the enhancements to Java made between 11 and 17 can be found at https://openjdk.java.net/projects/jdk/17/jeps-since-jdk-11.
- An outline of things to consider and check before finalising your Java 17 upgrade plans, including the timeline for third-party vendors of the tools and libraries your applications depend upon having tested compatibility of their software with Java 17. And also testing whether it’s possible to run existing releases of your apps on Java 17 with a view to phasing the upgrade effort and reducing risk.
Given Java 17 is an LTS release, it delivers several valuable enhancements, and will be supported by third party software vendors as well as JDK distributors for several years to come, I will certainly be recommending our business now targets it as our preferred version of Java for running production applications, including upgrading existing Java applications running on Java 11. I expect most other businesses will be doing the same. And for this reason I expect to see Java 17 becoming the most broadly adopted version of Java in enterprises over the course of the next couple of years.
Thanks.
Neil Brown 