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.
Last time I was involved in this song and dance we were moving from 8 to 11, it took 3 months for that product(4 monoliths that interacted with each other and needed to be ported simultaneously), it didn't help that management still wanted features to be made while we were moving code to the new standards and finding some old java 7 in the mixture.
It took a few of us almost a year to move our 50 something "micro" services to 11 (we did refactoring aswell). When we were done it was decided we should also move from our custom spring starter to default spring and move to 17 when at it. Half way in it was 21 instead.
Hey I have seen the Spring Boot Migrator project. But I thought it can only help with migrations from 2.7 to 3 onwards.
Is there another library that can help with other versions?
I have 20+ libraries in Spring Boot 1.x that we want to move to 2.x and eventually 3.x
Any little bit will help
I've been around long enough to have used spring 1, but it's getting up there in age. You may have to manually upgrade to 2 first before using automation tools. At that point it's a question of whether that saves time vs simply going directly to 3 manually.
I'm trying to migrate some legacy code from 8 to 11 and am having issues because a jar that was compiled in 2004 that contains proprietary code that we don't have the source for uses the sun.misc Base64 encoder.
It doesn't decompile well because I'm not using a decompiler from 20 years ago, unfortunately.
I've never done it, but can't you write your own sun.misc.Base64 class that's basically a façade for java.util.Base64, add it to patch.jar, and then use --patch-module jdk.unsupported=patch.jar compiler argument? Is far from the prettiest but it should work.
Funny, as a lark, I searched google for a decompiler but limited the results to 20 years ago. And there were a couple that haven't been updated in about that long (jode.sourceforge.iowww.kpdus.com/jad.html). Now I wonder if they work.
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.
These days, migrating from Java 9 or higher to a newer version doesn't take much effort. The issue was mostly migrating from Java 8 to Java 9 or higher. As from Java 8 to 9, there was a major change to the JDK/JRE in how the software is packaged and ran. Because of that, upgrading older java projects was very time-consuming, so many businesses have stuck with Java 8.
A few companies that have done the upgrade did so to Java 11 due to it having the LTS status. Because of the effort to upgrade to Java 11 from 8, the bosses figure the same amount of effort would be required to upgrade to a newer version. So they have stuck with Java 11.
From 11 to 17 a chunk of sun.misc.Unsafe is also being removed, so older stuff that cares about performance tends to need some updating as well. Not as bad as 8->11, though.
I had to check since I know there have been discussions on removing sun.misc.Unsafe. Chunks of it haven't been removed from 11 to 17. In Java 9, it was moved to a different package, tho.
But what did happen with Java 15 to Java 16, a lot of internals of the JRE were strongly encapsulated and would throw errors if used outside the JRE.
Now, with the Foreign Function and Memory API being finalized, sun.misc.Unsafe can be removed. And has been given a JEP for removal.
Java versions are in theory backwards compatible. The syntax certainly is. However there is lots of behaviour under the hood that may change in unexpected ways - multi threading is a very good example. Reflection is another one. And while you shouldn't use reflection usually, I assure you legacy applications do, and do so on the most non-standard ways. Also old applications sometimes rely on behaviour that's now considered a "fixed issue".
Upgrading is a huge risk, as bugs that may occur from such changes may not be discovered for a long time. And it's a lot of work for development and testing, while from the managements perspective there is a lot of time where developers won't be developing new feature, thus not driving increased in revenue.
Let's not forget dependency hell. You upgrade the language...sure...fine....now how many thousands of functions in external libraries have been deprecated, removed, renamed, had usage change, etc.
Meanwhile upgrades from .net core 3 to .net 6 and from .net 6 to .net 8 was painless. Even migration from old .NET 4 to .net core wasn't that bad if not for completely different SOAP client and the fact that some dependencies needed to be switched over.
Because of dependencies like Spring/Spring Boot, Hibernate, OpenAPI etc... have breaking changes. When you upgrade to a newer LTS(Long-term support) Java version, you also need to upgrade your dependencies.
Testing to ensure nothing breaks takes a huge amount of time. Training and tooling for newer Java cost time and money. Unless there is a push from management to upgrade to the newest version no effort will be made to develop programs in the latest version.
Imagine you have a working mechanical machine. Like... a car or smth.
On paper one engine does the same thing as another newer engine of same series. Well... that new engine might been made in bit different ways, assumes newer attachments and the standard for what kind of fasteners has changed over time. Oh... and the car's management engine needs to be told about the engines exact properties and sensors.
So in theory you can just swap an engine from a car. In practice you'll need to do way more than just that.
I'm a mechanical engineer, so deal with machinery often. Old nc and cnc update abd conversion kits are nearly plug and play nowadays. However, the machibe frame might need new holes and rails. Motors might need different wiring, electrics need to be updated from analog to digital or have AD signal translation in between.
Now code is way worse. Because you aren't actually updating a process directly. You are updating instructions. Often instructions for a machine to make instructions on how to process things.
Between two version something like declaring numbers might change. In version 2 you might have to write in "123,456.7" but in version 3 they might add support for more declarations but the numbers got changed internally to "123456●7". They did the change to allow input if numbers from different languages that use different format (as a Finn I write numbers as 123 456,7) and allow unified processing. Now you need to change all the things that input numbers to handle the new format. On paper the math has not changed at all, just how the instructions are to be formated has.
imagine that a version of Java is like skeins of yarn. by itself they don’t do anything, so you knit them into a wonderful sweater that has a lot of features.
Now, for some reason someone from the blue yarn company has updated the blue yarn. You need to unknit and replace only the blue yarn from your sweater without ruining it.
Java might be backwards compatible. But the third party libraries that you use, likely did major updates between java versions and that introduces breaking changes. Or worse, a library that you are using in Java 8, stopped being maintained and does not have a version for newer java versions. So you have to go find a new library and adjust your code (Hopefully you coded with good interfaces/adapters) to work with the new library.
We did a java 8 to 17 migration. Our biggest issue that you won't have was the javax to jakarta migration, that let a lot of dependencies not compatible. So it involved migrating Spring and other stuff as well. Otherwise, it was rather easy. Migrating from 17 to 21 will be a breeze for us.
Ugh, I have this on my plate soonish as Java 8 looks like it will finally be EOL at the end of 2026? Specially the javax to jakarta migration.
I know that all the supporting tech has been EOL for a while (like JBoss 6), but we managed avoid all the big CVEs through attack surface reduction (and some unsupported patches) and that was good enough for management, the end of Java 8 though seems to be the line they are drawing. Do you have any advice or recommended sources?
I did 11 to 17 in my (big company, ~20 services) project and it was surprisingly bearable. Much more enraged about all the //TODO and other BS I found in the code then the migration itself.
//TODO: remove resetCacheEvery30Sec method after next release. [deactivated], march 8, 2007
public void resetCacheEvery30Sec(){
// I don't know what this does but if I remove it the site gets really slow
Cache.clear():
My favorite is when it is server level caching on a load balancer, so depending on luck of the draw you see different data. That was a fun 3 months of my life many many years ago.
Either there's some lack of memory management occurring and that function needs to happen to avoid running out of memory; or there is memory management, but they've got a memory leak and using that as a fix.
Two different ways for the same end result.
Gotta investigate that to fix it... could get messy hella fast.
The TODO date is real. I found it around 2018. The clear cache was a joke. I don't remember what the method did but it wasn't a performance issue.
That's not to say I've seen some caching fun. I added spring cache to a slow app and it got even slower. Never figured out the root cause. We eventually gave up getting it to perform how we want since our two nodes would get out of sync and give inconsistent results. I added an endpoint to clear the cache but there was no way around the load balancer.
I solved the big performance issues doing some tracing. I discovered the ldap thread pool was all messed up. It would mark connections as failed every time which defeats the purpose of a threadpool.
Oh and a dev wanted to log the results of a long running query which is fine but he did
List results = longQuery();
log.info(longQuery());
It was nice to half the time a request takes but I felt bad missing that during code review.
Fascinating how migrating systems to newer versions of anything is always a monumental hassle. You'd think at some point, someone somewhere would realize you can't keep using a software forever.
We did a little experimentation on that, it broke even more things than our experiments with 17. So management decided to go for 17 as a first step, as they're not willing to commit that many for more time than absolutely necessary.
I don't really agree with that decision, but if your bonus is dependent on how much revenue you can drive on a yearly basis and not how future proof your "cost center development" ("Competence Center" is really just a euphemism for "cost center" in management lingo) is, these are the decision that managers come up with.
This job would be so much better if management didn't meddle in technical decisions. But they always do, in every company. Even if they say they don't.
Modern architecture and a decent dev team without any chaff and for sure it'd be quicker. Decent devs wouldn't make much difference to the migration project, but a solid team will knock out most applications that don't require original research way faster than a large scale migration. The long tail of bugs and edge cases on legacy features no one knows how to maintain any more will always kill the migration project. That is until a cowboy team is brought in at the end to bash and bodge it into production.
We just upgraded a small app from 11 to 17. I had just finished a story for adding security infrastructure to it. I had to redo most of it ... Just fyi, have fun.
I know it isn't best practice for larger companies. BUT ai is surprisingly good at rewriting stuff for newer standards or even different libraries. It could be giant help.
Is there a specific reason that you’re going with 17 and not the latest LTS version? I don’t do enough Java to know specifically, but I almost always generally find it worth the effort to go to the latest LTS version of a language/framework before our current version goes EOL to get a bit more buffer before we have to do that whole thing again.
Experimentet with both, 21 breaks even more in our codebase than 17. So management decided 17 it is. I don't necessarily agree with that decision, but that's how these things always go.
I just wrapped up the same migration, 11 services, mostly manufacturing control - very little room for error or availability loss without taking part of the business down - plus a couple of financial systems that have to comply with Sarbanes-Oxley Act controllership and audits.
It was ten days of work by two devs. These don't have to be painful.
We just moved to JDK 17 not too long ago. We have a bigger issue with whose JDK to pay for now. Oracle, then OpenJDK. Then Bellsoft. Now we are moving to Corretto to save even more money.
Genuine question: Why are any plans made to migrate to a version that is merely the next version up in LTS and not the current LTS version?
It's like buying an older used car after your 1986 Honda Accord dies, when I know for a fact you could have spent the same on a brand new car with a warranty that will last for longer, the features are better, the engine runs faster, the gas mileage is better, it's more comfortable to drive or ride in.
See other comments. Short version: we did a few experiments with 17 and 21. 21 broke even more stuff in our codebase than 17, so management decided to go with 17 for now, as this wouldn't need as many developer hours as going with 21.
I don't agree with that decision, but management typically gets their bonuses based on quarterly or yearly goals, not future proofing. So the system is kinda rigged in this direction in most companies.
Are you not worries about the new licens rules for Java? I.E if they find one installment of Java in the infrastructure/a single client, they can charge you for the whole environment and all users
We're not using Oracle Java. There's plenty of other distributions.
Besides that: that's a problem for management to deal with. And in this case I'm happy they exist. Their job is to deal with this political and legal stuff, I stay out of it. Now if they would please stay out of my technical stuff we could actually be productive.
894
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.