JDk 17

Be honest. It is more a question of when, rather than if you will upgrade.

Why should you actually upgrade your application?

I have noticed that a lot of applications are still on Java 8. Java 8 was released in March 2014. Businesses often say, we do not have time to invest now. They are saying we prefer to accumulate technical debt.

Non-experts often estimate that it is a lot of work, maybe even weeks or months of work to upgrade from one LTS version to the next LTS version of Java. It is seen as a challenge difficult to estimate, and is automatically postponed. That is not a good approach.

I try to make it more practical. Actually, in the case of the weeks to months' estimation, I often managed to migrate the application in a couple of days. It is often a matter of simply trying it, and if you are lucky, you manage to upgrade it quite easily. Depending on what dependencies you use or what code bases you use, it might be a bigger challenge.

Should we stick to using LTS versions, or should we use the latest versions of Java ^[1]? If you have the time available, I would recommend using the latest version of Java because you can use the new features and improvements. It always increases developer productivity and application reliability ^[2]. You have to do it every six months because you cannot use the new minor versions.

If you do not have that time available to upgrade every six months, you might opt to using only the long-term support versions. However, then, each time you need to upgrade your long-term support version, that actually might take quite a bit more time as well. In the end, I think staying on long-term support versions or using the latest version should not differ much in the investment in upgrading.

When we start developing against the new Java version, it is recommended to start with your local machine, get that up, and running first. Then upgrade your build environment, so it supports the latest version of Java. Get everything built and tested over there. Then at the end, release it to the other environments, including the production environment.

When upgrading Java, you might upgrade from 8 to 17 at once. If you have encountered any issues, it might be hard to pinpoint what has caused the exact issue.

Therefore, it might be better to do the migration, step by step. Maybe you migrate from 8 to 11 first, or maybe from 8 to 9. If you encounter any issues, you can easily see what has changed in that Java version.

Answers can often be found through Google or StackOverflow. That way, it is easier to get the upgrades done instead of in one big bang.

However, even after years of experience, I cannot estimate how long an upgrade will take without having in-depth information about the project. A lot depends on how many dependencies your application has. Often, upgrading your dependencies to the latest version resolves many of the issues that would occur during a Java upgrade.

How do we move forward? Now we start by compiling the source code on the new Java version, we run it. If that succeeds, and we make the necessary fixes, we go to running the unit tests. If we fix that as well, we can package the application, and in the end, we can run the application. Based on the nice ingredients, we should get a nice result.

The official list of new features is

The new features you should use on a daily basis are described below. They will impact the appearance and legibility of your source code.

Records [1] are immutable classes. A record and all associated operations are defined in one statement.

Sealed classes are a powerful construct to constrain your inheritance hierarchy.

A preview of pattern matching for switch extends the language of patterns in Java. It allows switch expressions and statements to be tested against a number of patterns, each with a specific action. This enables complex data-oriented queries to be expressed concisely and safely.

Among the goals of this feature include expanding the expressiveness and application of switch expressions and statements by enabling patterns to appear for labels, relaxing the historical null-hostility of switch when desired, and introducing two kinds of patterns: guarded patterns, which allow pattern matching logic to be refined with arbitrary Boolean expressions, and parenthesized patterns, which resolve some parsing ambiguities.

In JDK 16 [2], the instanceof operator was extended to take a type pattern and perform pattern matching. The modest extension proposed allows the familiar instanceof-and-cast idiom to be simplified. The implementation of the boolean equals(Object o) method is reduced to one expression without any conditional statement. Try the new implementation in your code.