How to Upgrade to Java 21

Java 21 is chock-full of great features and if you're coming all the way from 17, there's a plethora of additions to use and get used to, but it's all for naught if you can't actually update. In this #RoadTo21 episode, we discuss all you need to know to update from Java 17 to 21: API changes that may require you to update your code (like the introduction of sequenced collections or bug fixes in Double/Float::toString and IdentityHashMap), ongoing deprecations (threading, security manager, finalization, and more) and changes in networking (like earlier URL validation and HTTP timeouts), encoding (UTF-8 by default and changes in date/time/unit formatting), the runtime (like removed options class loading), and tooling (like new warnings). We'll also go beyond the nitty-gritty details and see the bigger picture of how to best prepare and execute your Java and 3rd party updates by talking about inside.java, release notes, Quality Outrach, and much more.
~~~ Chapters & Links ~~~
0:00 Intro
1:40 API changes
sequenced collections: inside.java/2023/05/12/qualit...
XSL transformations: www.oracle.com/java/technolog...
Double/Float::toString: inside.java/2022/09/23/qualit...
IdentityHashMap: www.oracle.com/java/technolog...
3:44 Ongoing deprecations
Inside Java Newscast: • Future Java - Prepare ...
Thread degradation: inside.java/2022/11/09/qualit...
ThreadGroup degradation: www.oracle.com/java/technolog...
security manager - Inside Java Newscast #5: • Pattern Matching in Sw...
security manager - heads-up: inside.java/2021/12/06/qualit...
security manager - JEP 411: openjdk.org/jeps/411
finalization - Inside Java NEwscast #15: • What Happens to Finali...
finalization - JEP 421: openjdk.org/jeps/421
dynamic agent loading: openjdk.org/jeps/451
6:52 The more you know
Inside Java: inside.java
Java 20 release notes: www.oracle.com/java/technolog...
8:56 Networking
network interface names: inside.java/2023/05/08/qualit...
URL validation: inside.java/2022/11/22/heads-up/
stricter JNDI providers: www.oracle.com/java/technolog...
HTTP client timeouts: www.oracle.com/java/technolog..., www.oracle.com/java/technolog...
10:25 Encoding
UTF-8 encoding - heads-up: inside.java/2021/12/10/qualit...
UTF-8 encoding - article: inside.java/2021/10/04/the-de...
UTF-8 encoding - JEP 400: openjdk.java.net/jeps/400
CLDR v42: inside.java/2023/03/28/qualit...
13:52 Quality Outreach
website: wiki.openjdk.org/display/qual...
on inside.java: inside.java/headsup/
16:31 Runtime
biased locking: www.oracle.com/java/technolog...
G1 changes: www.oracle.com/java/technolog..., www.oracle.com/java/technolog...
ClassName/: inside.java/2022/02/10/qualit...
parallel-capable class loaders: inside.java/2022/11/14/qualit...
Metal - heads-up: inside.java/2022/04/27/qualit...
Metal - construction: • Metal Construction
19:02 JDK Tools
serialization warning: bugs.openjdk.org/browse/JDK-8...
JAR index: bugs.openjdk.org/browse/JDK-8...
jlink --compress: bugs.openjdk.org/browse/JDK-8...
jpackage --app-image: github.com/openjdk/jdk19/pull/9
20:31 3rd party updates
21:48 How to update
OpenJDK Archive: jdk.java.net/archive/
(Don't run outdated versions in production!)
23:39 RoadTo21 previews
~~~ ~~~
Tags: #Java21 #Update #Java #OpenJDK #InsideJava

[@hausi78]

So nice to hear about all those precious Java 17 and Java 21 features. If only Oracle would update WebLogic Server to be able to use a Java version > 11... 🤬

[@delabassee]

Please see blogs.oracle.com/weblogicserver/post/the-promise-of-using-java-virtual-threads-with-oracle-weblogic-server

[@shaunreich]

I think it would be very beneficial to mention OpenRewrite in all of these Java version videos
They've already got a lot of recipes to migrate and refactor, from spring to JDK versions. It can also rewrite to prefer more modern types and functions
The more attention this project gets, the more contributions, and the more assistance people will get, which will then help keep people on modern Java versions easier
Haven't used it yet myself though but it looks really promising, and can be broken down my JDK versions, run from the toolchain, or cli

[@nipafx]

OpenRewrite is definitely very interesting but I haven't used it neither and hence don't want to propose it as a solution on this channel. But I definitely recommend checking it out.

[@shounak616]

What's wrong with dynamic agent loading, I thought Mockito was a good UT Mocking framework? is there anything I should know about it?

[@diegoshevek5927]

You'll still be able to use it

[@nipafx]

There's nothing wrong with dynamic loading of agents but it should happen with the user's explicit consent and so it will probably require a command line flag in the future. As preparation, it now logs a warning.
Details: openjdk.org/jeps/451
NB: The descriptions usually contain lots of follow-up links and in this one, JEP 451 is among them. In case you don't want to have to wait for a reply to your question. 😊

[@RainerJung]

I'm building my application in docker images. I'm using the eclipse-temurin images. They don't have ea builds. As far as I remember, openjdk docker images are outdated, but they do have ea-builds.
Is there a recommendation which images to use?

[@delabassee]

Yes, the Oracle's setup-java action supports the Oracle JDK, the latest and greatest OpenJDK Builds *and* the OpenJDK Early-Access builds, see github.com/oracle-actions/setup-java

[@TomConder]

I spotted the Pandemic board game. Good taste!

[@stcattc]

@nipafx I have apps on gradle 8.3 with java 20 no docker, runs on bare metal (cpu pinning and other perfomance requirements).
How do you suggest a setup that can allow for building on 21/22 without having to wait until gradle 8.4 is releeaed? Even if I was to run gradle with java 20 which is supported, it still does not allow compiling to > 21.
Interested on your thoughts on an approach.

[@nipafx]

I'm far from a Gradle expert but I think their JVM toolchain is the way to go?

[@shaunreich]

I think Jvm tool chains is the answer as the other person said. This is really what you should use anyways regardless. This way you don't need to tie your runtime to your toolchain version. Plus, it ensures less variability. You ensure that all of your devs have the same JDK version from the particular vendor. It should allow you to say, run Gradle with 17 and compile to 20. Or is there a specific limitation for this with 21? I'm less familiar in this area

[@stcattc]

@@shaunreichyes seems to be the move. Strange how they don't mention this in their compatibility matrix. Wil give this a shot. Thanks for the tips.

[@delabassee]

Check inside.java/2022/12/12/sip073/ for some details on Gradle Toolchain

[@shaunreich]

​@@stcattcthat is a bit strange. Feel free to open an issue and or pull request to correct those docs for the next person like you, who runs into it

[@onebeartoe]

Update little by little, generational children!

[@michaelangelojohnsonlucas7552]

Java coffee and a Tannenzäpfle

[@nipafx]

I don't actually drink coffee, so I need other ingredients to adjust my chemical balance.😊

[@musashi939]

Haha metal construction work. I know that reference. ❤

[@nipafx]

That dude (and video) is amazing! 🤘

[@gugolinyo]

I hope you don't think when you chose a hashtag it becomes reserved for your channel only. Maybe take a look of what comes up for the hashtag first. And if you didn't, maybe change it now.

[@Jake-lc1lh]

I'll be coming from 11, so what else do I need to know

[@nipafx]

There are a few more things between 11 and 17 to look out for, but I don't think I collected them in one place as I did here. And I forgot all the small things, so you should really look into the release notes, particularly the sections I point out in the video at 8:23. On the larger side of things, you can look up JEPs 363, 372, 398, 403, and 407. I hope that helps. :)

[@mahee96]

⁠@@nipafx I am working on jdk 8 to 11 upgrade for our java stack applications, but I see that they used reflection a lot and some third party libs use it too.
so we faced issues with most packages and had to do -add-exports, -add-reads, -add-opens cmdline args to mitigate them. Now that in java 17, the cmdline based override is not present.
What do you recommend the key breaking changes that I need to lookout for upgrade to 17 coming from java 8 and been on java 11 for sometime

[@nipafx]

​@@mahee96 The command line arguments you mention are all present in 17 and are in no danger of being removed. You're probably thinking of --illegal-access, which was removed in 17 by JEP 403. I actually think that that is the biggest migration challenge for most projects because many didn't do the hard work you did and just slapped --illegal-access on. Other than that, I can't add anything to my comment above, where I listed a few JEPs and pointed our where to learn more.
(Sorry for the late reply, I missed the notification.)

[@mahee96]

@@nipafx sure Thanks, some major dependencies that used to work such as xstream (for serializing objects to xml) is having issues due this change because they use deep reflection to perform the serialization.
At the very least this gives me hope that we are at the end of the tunnel without having to bother about the overrides being removed any sooner.
Thanks for the reply, great content!

[@nonnnth]

Where I work, they’re still using java 8.

[@SahilSawant-td1pw]

Hey Java , really nice video! I was wondering if I could help you edit your videos and also make a highly engaging Thumbnail which will help your video to reach to a wider audience .