> Also, I’d argue this barely qualifies for the boy scout rule: does migrating the code to a more modern form of itself count as leaving it “neater than it was”?
"Barely" is an understatement. You just shouldn't do this as part of a big version migration. It's noise, and introduces more changes that could cause bugs, and then you end up wondering if the bugs were caused by the big version migration, or by all the little changes that were supposedly cosmetic.
Arguably you shouldn't make those types of changes on their own at all. If you're later refactoring the code for a "real" purpose, or making other type of changes in that area, sure, go ahead, the code that you're working on to their more modern forms. But otherwise they're akin to rewrites: the existing code works, and has been tested and debugged, and changing it just so it "looks more modern" is pointless.
Agreed. The challenge I had was that the juniors helping me out were obsessed with applying these low hanging fruit style modernisations because of an unqualified "it's better".
I had to sit them all down and explain a variant of your point and the one another poster made about second system syndrome.
"Minimum Boy Scout: Is this a controversial take? Of course you should leave things neater than when you found them, but after moving a project to Java 17 I had lots of lovely attempts to help by IntelliJ: “Can be a record!”, “Can be a text block!”, “Use pattern variable!”, “Replace with switch expression!” – these are all wonderful suggestions, but you are soon distracted by them and it will make the job take that little bit longer."
This seems to be a application of the second system effect noticed by Fred Brooks in the 1960s (that the second version of a system is extraordinarily dangerous because of all the "while we're in here why don't we..." opportunities)
From my experience the biggest PITA with switching to jdk 17 and beyond is the module system (jigsaw). Very few projects utilize this in practice and instead of being a step forward it's a source of annoying runtime errors and typically results in a --add-opens mess on the command line too.
Moving away from traditional JNI (especially with critical JNI natives) also complicates what used to quick and easy work. But at least Panama clearly comes with interop and compiler-level improvements.
Java 17 was mostly a positive upgrade. Although in my slow moving bank we still managed to do this a while ago and mostly for the same reasons, Spring Boot let us scapegoat it! Having security put in tooling they don't understand so that it alerts whenever something is vaguely out of date has been annoying for systems that aren't consumer facing but instances like this make it worthwhile.
Why is everybody migrating from Java 8 to Java 17 this week? Seems like this is not the first time I've seen this sort of thing on the front page in the last few days. Did some long term support thing happen?
We're doing 11->17. For our team it's some intersectional compatibility issue between Java, Apple silicon, and docker or something? I dunno, it all just works on my Linux machine.
I can't speak to this week but overall some of the newer JVM and language features that have landed have made more modern versions of Java a lot better.
I've been building on 21/22 recently and the amount of boilerplate you need for some basic stuff like serving routes flask-style has dropped dramatically.
Edit: It's possible though that it relates to the CentOS 7 EOL.
kelnos|1 year ago
"Barely" is an understatement. You just shouldn't do this as part of a big version migration. It's noise, and introduces more changes that could cause bugs, and then you end up wondering if the bugs were caused by the big version migration, or by all the little changes that were supposedly cosmetic.
Arguably you shouldn't make those types of changes on their own at all. If you're later refactoring the code for a "real" purpose, or making other type of changes in that area, sure, go ahead, the code that you're working on to their more modern forms. But otherwise they're akin to rewrites: the existing code works, and has been tested and debugged, and changing it just so it "looks more modern" is pointless.
paltaie|1 year ago
I had to sit them all down and explain a variant of your point and the one another poster made about second system syndrome.
readthenotes1|1 year ago
This seems to be a application of the second system effect noticed by Fred Brooks in the 1960s (that the second version of a system is extraordinarily dangerous because of all the "while we're in here why don't we..." opportunities)
bitcharmer|1 year ago
Moving away from traditional JNI (especially with critical JNI natives) also complicates what used to quick and easy work. But at least Panama clearly comes with interop and compiler-level improvements.
Jigsaw though... I can't even.
happymellon|1 year ago
Thank you Spring Boot, and long may it continue.
michael_michael|1 year ago
X, or how I learned to stop worrying and love Y
X for fun and profit
A tale of two X
X considered harmful
thenewwazoo|1 year ago
ant6n|1 year ago
X considered harmful considered harmful
Al-Khwarizmi|1 year ago
X is all you need
I find it especially annoying as it's never even true.
unknown|1 year ago
[deleted]
CobrastanJorji|1 year ago
mrkeen|1 year ago
BeefWellington|1 year ago
I've been building on 21/22 recently and the amount of boilerplate you need for some basic stuff like serving routes flask-style has dropped dramatically.
Edit: It's possible though that it relates to the CentOS 7 EOL.
kyawzazaw|1 year ago
unknown|1 year ago
[deleted]
unknown|1 year ago
[deleted]
motoboi|1 year ago
[deleted]