3 ms·

Upgrading a Java 8 application is not easy if you have a very huge code base. The article focus on performance considerations, what about migration costs?

dwohnitmok 6y ago
I'm a bit curious because of Java's story around backwards compatibility: what exactly makes a huge code base difficult to upgrade? You can use all the same byte code and just run it in a newer JVM. The only concerns I can think of are dev ops related, not code related. Even there I'm struggling to think of big blockers (might have to remove some deprecated JVM flags). The only things I can think of are extremely precise tuning of JVM parameters for one particular use case and then needing to double-check that your performance hasn't degraded based on that tuning. EDIT: After seeing some responses I should clarify, especially because I wasn't all that clear in my initial question. The article is mainly talking about upgrading the JVM rather than upgrading your compiler. So just take all your class files and dump them into a new JVM rather than regenerating your class files from a new Java compiler. Has this caused substantial problems for people in the past?
- swsieber 6y ago
  There was a lot of proprietary sun stuff that got yanked out in the 8 -> 11 shift, along with the addition of the module system that makes reflection to hack into dependencies a lot harder (IIUC). Upgrading 8 -> 11 is a lot harder than upgrading 11 -> 17 will be.
- mrighele 6y ago
  One example that comes to my mind: libraries that handle bytecode manipulation (e.g. javassist) may require to be updated because they give new and strange error if they meet newly introduced bytecode. Since those libraries are often used by high level frameworks like Spring, this means that to move to a new Java version you have to update your framework. These most often means new API, new bugs, new regressions...
- cashewchoo 6y ago
  I did a 6 to 8 migration at $lastjob. The upgrade was smooth except for 2 issues: * It exposed a kernel panic bug in our Linux kernel when Hadoop applications de-allocated huge amounts of RAM at once (e.g. a Spark program with a 100GB heap exiting suddenly would panic the system) * It introduced a weird UI behavior change in Swing in one of our desktop apps. In fairness, whoever wrote the app first did some weird unnecessary shit with JComboBoxes, but it was still somewhat odd to me that the behavior changed. The bug was like, when previously if you clicked a box it'd swap it out for a JComboBox that had the previous content of the non-combobox-view-thingy that was in its place. On 8, for some reason it would always be blank and discard the old content. Don't quote me on this description, though. It was a while ago and it was a weird interaction regardless. So, idk. It's always something. Software, eh?

dwohnitmok 6y ago

I'm a bit curious because of Java's story around backwards compatibility: what exactly makes a huge code base difficult to upgrade? You can use all the same byte code and just run it in a newer JVM. The only concerns I can think of are dev ops related, not code related. Even there I'm struggling to think of big blockers (might have to remove some deprecated JVM flags). The only things I can think of are extremely precise tuning of JVM parameters for one particular use case and then needing to double-check that your performance hasn't degraded based on that tuning. EDIT: After seeing some responses I should clarify, especially because I wasn't all that clear in my initial question. The article is mainly talking about upgrading the JVM rather than upgrading your compiler. So just take all your class files and dump them into a new JVM rather than regenerating your class files from a new Java compiler. Has this caused substantial problems for people in the past?

swsieber 6y ago
There was a lot of proprietary sun stuff that got yanked out in the 8 -> 11 shift, along with the addition of the module system that makes reflection to hack into dependencies a lot harder (IIUC). Upgrading 8 -> 11 is a lot harder than upgrading 11 -> 17 will be.
mrighele 6y ago
One example that comes to my mind: libraries that handle bytecode manipulation (e.g. javassist) may require to be updated because they give new and strange error if they meet newly introduced bytecode. Since those libraries are often used by high level frameworks like Spring, this means that to move to a new Java version you have to update your framework. These most often means new API, new bugs, new regressions...
cashewchoo 6y ago
I did a 6 to 8 migration at $lastjob. The upgrade was smooth except for 2 issues: * It exposed a kernel panic bug in our Linux kernel when Hadoop applications de-allocated huge amounts of RAM at once (e.g. a Spark program with a 100GB heap exiting suddenly would panic the system) * It introduced a weird UI behavior change in Swing in one of our desktop apps. In fairness, whoever wrote the app first did some weird unnecessary shit with JComboBoxes, but it was still somewhat odd to me that the behavior changed. The bug was like, when previously if you clicked a box it'd swap it out for a JComboBox that had the previous content of the non-combobox-view-thingy that was in its place. On 8, for some reason it would always be blank and discard the old content. Don't quote me on this description, though. It was a while ago and it was a weird interaction regardless. So, idk. It's always something. Software, eh?