JDK 16: Should You Upgrade or Wait For 17?

JDK 16, set to be released this March, has a considerable amount of new features included, all outlined in this InfoWorld article. But should you move over to 16? Or should you wait for the next long-term support release with JDK 17?

We got in touch with Java Champion Trisha Gee to learn about her favorite features, why JDK 16 is relevant and whether you should upgrade now or wait for 17.

What are some of the key features in JDK 16?

Trisha: There were a few things which are really really cool, a few of the preview features which were in 14/15 are now standard features in 16 including:


Records are really cool. I’ve been using records as a preview feature since they came in 14. If you’ve used other JVM languages like Kotlin, it’s similar to things like data classes, and it encapsulates a simple data class with a class and a few fields and you can do it with minimal lines of code. It seems like a silly feature, but it’s really helpful because when you’ve just got a class which is just these fields that are in here with no extra code, you can see at a glance there’s nothing special about this class, it’s just a data class, so it makes reading code much much easier. I think it’s really cool and, I’d really like to start seeing developers start using that.


Pattern matching for the instanceof operator will make code a lot simpler and will lead to more interesting pattern matching features in the future. It’s all about reducing boilerplate and increasing readability.


Sealed classes are cool for library developers, allowing you to take full control of your class hierarchy, so that nobody can abuse your class hierarchy by implementing stuff that you didn’t mean them to override or implement. It’s a preview feature for 16, but it should mean if it’s all going okay, it will be a standard feature for 17.

Trisha: As for the new new stuff…


There is a new vector API which is an incubator. I don’t know much about this, but for people that are doing vector type applications, I think that’s cool for them as it can be built into the JDK and can be used for some hardware acceleration stuff.


Lets you build deployables for your application. It’s built off some of the changes that came off the jigsaw and j-link. It’s going to make deploying your app much much easier. Now a standard feature in Java 16.

Why is JDK 16 relevant?

Trisha: There’s a few things…  there’s a lot of features in this release. These small 6-month releases usually have 4 or 5 new features, and there’s a lot in this one. Particularly relevant for this release is that the next release is 17, which is the next long-term support release.

We can expect enterprises to upgrade to the long-term releases, not to the 6-month releases. So enterprises will generally not be adopting 16 but will be looking at 17. The reason 16 is relevant is because the standard features that are in 16 we can of course expect in 17 and some of the features we’re seeing in 16 are laying the groundwork for some interesting things that are probably going to be ready for 17.

So I think 17 looks like a really compelling long-term support release. All those people looking to move from 11 to 17 of course will get all the features from 12,13,14,15,16 and 17. And there’s been a lot of interesting features from 11 to 17 and hopefully some of these things that are coming in 16, particularly some of the under the covers type stuff like:

  • Improvements to the garbage collection
  • Support from different operating systems
  • Forigen memory access API

Some of these tools will be mainly helpful for library devs and framework devs. Normal devs won’t necessarily be using some of the features from JDK 16, but will be benefiting from them if the library developers are using them to create more usable APIs or faster libraries and frameworks.

Gives the chance for lib devs to build off the features of 16 so they are ready for 17 as well.

Should people upgrade to JDK 16… or wait for 17?

Trisha: I think 16 is an interesting springboard for people and enterprises to adopt 17.

The jump from JDK 8 to 11 is perceived to be a little bit risky, and so we find a lot of people and enterprises are still stuck on JDK 8. 17 needs to be compelling so people jump off 8 and get moving on this new release cadence with all these new features, and currently 17 is looking like an interesting release for that.

However, there are a few internal changes in 16, they build off some things that came off 9 like jigsaw and encapsulation to make sure java is as safe as possible. This will make it tricky for people to jump straight from 8 to 17, because all of those internal changes are going to require you to (most probably) make changes to your code.

What i’m seeing from 16 is that it really pays for developers and teams to be making sure they have made the leap from 8 to 11, so they have made the slightly hairy migration from 8 to 9, I think it’ important to jump from 8 to 11, which I’ve written about on infoQ, and then once you’ve made the jump from 8 to 11 it will be a more incremental jump from 11 to 17. 

Once you get to 17 you will get all these new features, all these new garbage collectors, all these new APIs; you get records, you get, potentially, the libraries and frameworks you’ll likely use with these new features which will help create faster, more maintainable code.

Some of these internal changes will help with performance in 16.