What is it about Java where companies are hesitate to upgrade? Do the Java releases always bring breaking changes or are the companies that use Java have a culture of not prioritising tech upgrades?
I think many companies don’t actively maintain a large portion of their code base at all. So any amount of work, no matter how small, involves a “project” and “budget” and “approvals” to even assign somebody to the task of upgrading.
Then you have the testing and due diligence from whomever actually uses the thing.
Java for this flash in the pan mobile shit? Sure, they like breaking things.
Java for enterprise? No. They’re probably only just finished converting that COBOL system to it, and they started 20 years ago. People have died while making it. They will never change anything.
I think it was 5 that decided to change everything on the parser level, and 11 that decided to change everything on the modules level.
Outside of those, Java has always been extremely backwards compatible. But last time I checked the ecosystem still didn’t recover from that module semantics change.
Java 8 to 21 + spring boot 2 to 3 brought the need to change a lot of dependencies, but often they were drop-in replacements. That was mostly Jakarta stuff. On the Spring side, a lot of things we used were deprecated, but that was not related to the Java version.
Did not take a huge amount of time to upgrade anyway. But maybe our systems weren’t the most complex in the first place, a lot of our applications were pretty small.
That can also have its own dependencies. I tried to update some relatively simple apps that ran on Java 8 with some Spring libraries (not Boot) and had to deal with the Jakarta stuff to handle it… Only to discover that the Weblogic Application Server we use doesn’t support Jakarta just yet (or probably more accurately, STILL doesn’t!)
What is it about Java where companies are hesitate to upgrade? Do the Java releases always bring breaking changes or are the companies that use Java have a culture of not prioritising tech upgrades?
I think many companies don’t actively maintain a large portion of their code base at all. So any amount of work, no matter how small, involves a “project” and “budget” and “approvals” to even assign somebody to the task of upgrading.
Then you have the testing and due diligence from whomever actually uses the thing.
Java for this flash in the pan mobile shit? Sure, they like breaking things.
Java for enterprise? No. They’re probably only just finished converting that COBOL system to it, and they started 20 years ago. People have died while making it. They will never change anything.
I think it was 5 that decided to change everything on the parser level, and 11 that decided to change everything on the modules level.
Outside of those, Java has always been extremely backwards compatible. But last time I checked the ecosystem still didn’t recover from that module semantics change.
Java 8 to 21 + spring boot 2 to 3 brought the need to change a lot of dependencies, but often they were drop-in replacements. That was mostly Jakarta stuff. On the Spring side, a lot of things we used were deprecated, but that was not related to the Java version.
Did not take a huge amount of time to upgrade anyway. But maybe our systems weren’t the most complex in the first place, a lot of our applications were pretty small.
That can also have its own dependencies. I tried to update some relatively simple apps that ran on Java 8 with some Spring libraries (not Boot) and had to deal with the Jakarta stuff to handle it… Only to discover that the Weblogic Application Server we use doesn’t support Jakarta just yet (or probably more accurately, STILL doesn’t!)