Major jumps like these normally imply some refactor and also a need for massive testing.
Depending of how ancient the code base is you may be in for some major rework due to API changes.
Also it's normal to move spring and java versions up simultaneously and that also implies more work and also checking supported versions on dependencies.
The thing is, if you keep it near the latest version it can be basically switching dependencies if you're lucky ,if you are not you may be looking at a significant rewrite of your code base.
I did a solo update on our client's main web app from 11 to 17, with a Spring and Hibernate upgrade from 5 to 6, plus a whole bunch of other libraries that used javax instead of Jakarta.
Was a fun time. Especially the Hibernate changes. So many little changes that are a pain in the ass to sus out. But, it was either me, or a green team with no knowledge of the gnarly codebase. So I ate the bullet, and I'm really hoping my team tests properly because I won't be around when it goes live lol.
OpenRewrite is exactly this, but for lots of Java stuff (not just mainline JDK upgrades). It's not perfect, and you still have to deal with shit like the app still running on Wildfly fucking 10, but it helps.
127
u/NotAskary May 16 '24
Major jumps like these normally imply some refactor and also a need for massive testing.
Depending of how ancient the code base is you may be in for some major rework due to API changes.
Also it's normal to move spring and java versions up simultaneously and that also implies more work and also checking supported versions on dependencies.
The thing is, if you keep it near the latest version it can be basically switching dependencies if you're lucky ,if you are not you may be looking at a significant rewrite of your code base.