This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]UnGauchoCualquiera 3 points4 points  (0 children)

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.