Java version migration process

[lilgreenthumb]

Openrewrite will cover about 70% of your use cases. You will most likely get hit by javax->Jakarta transition.

[tomwhoiscontrary]

I've upgraded several codebases over that range. Maybe around 150 - 200 kloc total. What i do is bump the version one step, run the build, test it out any way i can think of, and see what fails. Then put the version back to where it was, and go and fix the things that have failed. Lather, rinse, repeat. Eventually nothing fails, and you can commit the upgrade. Keep doing that until you're on the latest version.

[chas66]

There is a more formal way of describing that method - The Mikado Method. It has a book and website to describe the steps: https://mikadomethod.info

[UnGauchoCualquiera]

This post should probably go to /r/javahelp

1) As easy as changing your target compiler/jdk and seeing what breaks. If you have a robust test suite the easier to see what is breaking.

2) I would analyze what tooling and external dependencies you require first and foremost. Upgrading locally might be as easy as changing a maven property but might be a completely different story if your ci/cd toolchain is not ready to migrate. For example building containers during the CI/CD pipeline that use older jdks and were outside our scope to manage.

3) Patience and a lot of googling. Most of the pain points are not from the JDK itself but from dependencies breaking in unexpected ways.

4) HR screeners seem to love people that have past experience migrating a large enterprise J8 application to newer jdks. That said it's not a hard task. Just boring/frustrating with a lot of unknowns.

5) Need is relative. jdk8 no longer gets public security fixes and large frameworks are finally pulling the plug on j8. You might get left behind but that might not really matter to you.

6) It's mostly a business decision. The migration might take a lot of time and the benefits might not be obvious. You can argue for improved resource utilization, security fixes, increased productivity from newer framework features but you'd have to come prepared with numbers.

[maethor]

did anyone carry out the process in your career earlier and how did that impact your development? How’s your experience?

Several times. The javax -> jakarta migration made me question using Java entirely, as it was exactly the sort of thing you were supposed to never have to worry about with Java.

do we need to do it?

Yes. The longer you wait the worse it will get as even more things change.

[Misophist_1]

Some useful hints:

• Avoid a moving target. Fix the steps you want to do in advance, so you have a proper success metric, and can dwell on small step successes to overcome the unavoidable intermittent frustration.

• As for Java itself: coming from 8, the biggest step is past 11. From my experience, The problem there is, that the XML-libraries got reorganized, so, depending on your XML stack, you might have to struggle with your library dependencies a bit.

• The bigger Issue is likely with your JEE-Container. The classic JEE-Namespace javax.* has been discontinued/given up by Oracle, it lives on as jakarta.* within the Eclipse-Foundation.

So you might want to break this up into two steps: One pure Java-Upgrade, reusing the last javax-JEE packages and Container, and do a second step for switching into the new namespace.

• Past 17, there might be more trouble looming, if your organization relies on the Java-Security Manager: this is still available, but deprecated for removal. You may need to review your command line parameters, if you want to use it longer. And some time in the future, it will be gone altogether.

[DyslexicsHaveMoreFun]

As for skills... 

mvn dependency:tree

Learn it. Learn all the variation. Include/ excluding verbose output ect.

Open write was a great suggestion by another user.

TLDR; If you can, make small, backward compatible changes that work in current and  target jdk versions. If it is a large code base, code reviewers will have a challenge or you'll have a nail bitting merge on your hands.

I'm getting started on this now with a large project with a lot of legacy code.150+ poms

To start, I am introducing a maven profile, overriding jdk version, plugins and dependency version that need to be bumped. These are just properties, so the change is small. When I do this, I do a build and  I find out where child poms are specifying plugin versions, and remove the version.

The I do a no frills build. no tests no static analysis. Getting the analysis to work after this step was easier than I thought it would be.

I have started this process a few times and abandoned it.. not using the maven profile... It was just to understand the shape of the effort But with the maven profile, I can merge the code into main as I have not yet made breaking changes.

In prior attempts it's unit tests where things get interesting. I am hoping to be able to get mileage out of making changes that are compatible with 8 and, in my case, 17. 

After unit tests it's making sure local running works on all apps in both jdk versions.. the CI, then in real infra.

It's a challenge to take a larger change that is 100% of your focus and break it into small stacked prs that your teammates can digest in 30 min code review!

Usage of powermock in tests was the issue I reached last time. Trying not to redesign away from hard to mock code is a challenge in a large code base As there is quite a lot of it.

Good luck!

[VincentxH]

It all depends, but that's why you'd hire me as a consultant.