3 ms·

Moving to Java 17 or how I learned to stop worrying and love NoSuchMethodError

27 points by paltaie 2y ago

michael_michael 2y ago
There are a few blog title/conference talk title cliches that I would love to toss in a volcano and never hear again: 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 2y ago
  Most Hated: A tale of two cliches for fun and profit, or how I learned to stop worring and love things considered harmful.
  - devin 2y ago
    Alternatively: A tale of two things considered harmful, or how I learned to stop worrying and love fun and profit
  - shrimp_emoji 2y ago
    > how I learned to stop worring and love things considered harmful That just sounds like my life.
  - ebiester 2y ago
    That said, if someone could deliver on a talk that talked about bucking software developer fashion to get things done, I'd be ready to watch that.
- ant6n 2y ago
  Also X considered harmful considered harmful
- Al-Khwarizmi 2y ago
  And in ML/NLP papers: X is all you need I find it especially annoying as it's never even true.
- deleted 2y ago
  [deleted]
motoboi 2y ago
[flagged]
CobrastanJorji 2y ago
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?
- mrkeen 2y ago
  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.
- deleted 2y ago
  [deleted]
- BeefWellington 2y ago
  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.
- kyawzazaw 2y ago
  we did it in my entire company too. massive massive pain. 8 -> 17
bitcharmer 2y ago
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. Jigsaw though... I can't even.
deleted 2y ago
[deleted]
happymellon 2y ago
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. Thank you Spring Boot, and long may it continue.
readthenotes1 2y ago
"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)
kelnos 2y ago
> 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.
- paltaie 2y ago
  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.

27 points by paltaie 2y ago

There are a few blog title/conference talk title cliches that I would love to toss in a volcano and never hear again: 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 2y ago
Most Hated: A tale of two cliches for fun and profit, or how I learned to stop worring and love things considered harmful.
- devin 2y ago
  Alternatively: A tale of two things considered harmful, or how I learned to stop worrying and love fun and profit
- shrimp_emoji 2y ago
  > how I learned to stop worring and love things considered harmful That just sounds like my life.
- ebiester 2y ago
  That said, if someone could deliver on a talk that talked about bucking software developer fashion to get things done, I'd be ready to watch that.
ant6n 2y ago
Also X considered harmful considered harmful
Al-Khwarizmi 2y ago
And in ML/NLP papers: X is all you need I find it especially annoying as it's never even true.
deleted 2y ago
[deleted]

motoboi 2y ago

[flagged]

CobrastanJorji 2y ago

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?

mrkeen 2y ago
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.
deleted 2y ago
[deleted]
BeefWellington 2y ago
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.
kyawzazaw 2y ago
we did it in my entire company too. massive massive pain. 8 -> 17

bitcharmer 2y ago

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. Jigsaw though... I can't even.

deleted 2y ago

[deleted]

happymellon 2y ago

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. Thank you Spring Boot, and long may it continue.

readthenotes1 2y ago

"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)

kelnos 2y ago

> 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.

paltaie 2y ago
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.