Java version: When to migrate? [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 11 months ago.

Improve this question

About 4 years ago, where I was working, software was still being developed with Java 7 + Swing.

It took me a couple years, but we could finally migrate to Java 8 + JavaFX, two years after that.

Now I intend to migrate again. This upgrade, however seems more complex at a glance. While Java is the most I have developed, I am by no means knowledgeable on this topic.

What is the best practice on upgrading versions, regarding Java? Should I only migrate to LTS versions? (In which case, I would go from 8 to 11) Is there any other favored version at the moment?

Keep in mind that this is intended for software developed for a production environment, and both, stability and maintenance are my main concern.

Should there be any concerns with software still being developed under JavaFX? Along with the new Java version, should I change to another GUI-module?

Please give me guidance, Gurus!

Answer 1

To even begin an answer to this topic and others like it, we have to answer the following questions:

• What's the risk if I don't upgrade? Working software is king, so if the risk is low enough it may be worth skipping a version.
• What is the impact of upgrading? Is it a simple upgrade to the Java runtime, or do I have to change code to work around deprecated APIs?

That's analysis work you have to do yourself. However, once you have the answer to those questions, you can formulate a plan.

There's a couple scenarios that are common in these situations:

1. The customer requires the tool to run on supported software. Java 7 and Java 8 are no longer supported. At the time this answer is written, Java 11 is the current LTS with Java 17 the next scheduled LTS.
2. If the tool is no longer needed, or there are better alternatives, the customer may decide to take the opportunity to shut down the project.

In the first scenario, the risk of not upgrading is being in violation of your customer's policies. If you continue to violate those policies than your contract will most likely be cancelled. However, if the impact is high, you can negotiate the amount of time you need to get into compliance.

In the second scenario, the customer would have already decided to cancel the project so there is no point in spending any effort upgrading.

Keeping Up to Date

When establishing a policy for how often you upgrade you need to understand a couple of metrics:

• How often the platform is upgraded -- In Java's case that is every 6 months, with LTS releases supported for 3 years. All versions that are not LTS are no longer supported as soon as the new version is deployed.
• How quickly can you absorb the changes -- In your scenario it takes 2 years each time. Some projects can do the upgrades in weeks.

Considering your platform upgrades are more extensive, it would make sense to only stick with Java's LTS releases. If you could turn around changes in a few weeks, then you could keep up with Java's latest and greatest versions.

You also have to consider your alternatives. Just because Java's JDK and OpenJDK keep a 6 month release does not mean all alternative Java Virtual Machine platforms are the same. For example Amazon's Corretto implementation of Java only keeps up with the LTS releases. In that case you would follow suit.

General Advice

At the beginning of your release planning, decide which components need to be upgraded--even if it is just a patch version. The benefit of staying current with the patch levels is that typically they contain security fixes. Patch releases are typically low risk and don't require code changes to support.

When your platform upgrades whole version numbers there's more risk involved so tread carefully.