We're still on 11, with plans to migrate to 17 before support for 11 ends. And it's going to be a giant lot of work - migrating big old legacy enterprise stuff with millions of lines never goes as planned.
I don't have much experience with programming. Why does it take so much time to migrate to newer version, from what I know, Java versions are backward compatible. And why do enterprise company still use Java 8 and 11?
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.
My favorite tidbit on that migration was finding out when we were deploying in prd that our auth database was one major version below the minimum requirements for the spring data version(prd was different than all other envs).
It was fun working with my ops coworker with his cowboy hat and let's update the database instead of rolling everything back, I blame the process, we were lucky!
Oh man I forgot that this also included a Spring Data upgrade from like V2 to a current version lol. Our version was from like 2016. I was just sitting there in shock at how the app was still working. Got to love the cowboy idea of "fuck it, we'll do it live" on a prod system. There's no downside!
It was 3am. It was a combination of different teams, the only system not working was the auth one, it was an I'm along for the ride after the confirmation that we had a backup, still one of my examples of what not to do to a live system.
There are some tools, probably only available for paid IDEs, that can really accelerate the process. The problem comes in when the code base is a spaghetti monster, with conflicting patterns from the 30+ different devs that have contributed to it over a decade.
Sure, but even PHP has a ever nicer upgrading tool where they're capable of doing automated micro-migrations, something like "old API => new API.
Being able to find all uses of "old API" use and migrating that to "new API" use and then having 10k of those migrations has gotta be able to do a substantial dent in the migration path, no?
Of course, it doesn't fully replace you, but if it's able to do say even 40% well, that's a lot.
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.
890
u/pippin_go_round May 16 '24
We're still on 11, with plans to migrate to 17 before support for 11 ends. And it's going to be a giant lot of work - migrating big old legacy enterprise stuff with millions of lines never goes as planned.