8 ms·

Ironically they then went ahead and made a massive change in Java 9 that, for the first time in Java's history, broke pretty much everything. Still angry about

Ironically they then went ahead and made a massive change in Java 9 that, for the first time in Java's history, broke pretty much everything. Still angry about that...

szundi 3y ago
Was it more than internal lib references that one was not supposed to do anyway?
- cogman10 3y ago
  Pretty much. Most of the breaks came from touching the likes of "sun.misc.Unsafe". Java versions 9->~17 added new jdk features (such as VarHandles) to allow for the safe interactions that sun.misc.Unsafe exposed. Libs had to update to use these new patterns with 9 being the worst hurdle. There was also a change to how packages could be named that messed with stuff. 2 jars putting stuff into stuff like `javax.annotations` was a big no-no that broke with 9.
MichaelNolan 3y ago
Hopefully there should never be a repeat of that now that they have strongly encapsulated jdk internals. My understanding is that (nearly) all of the migration headaches from 8 to 9 were caused by libraries that were using improperly using jdk internals.
- saghm 3y ago
  Devil's advocate: anything that's possible for a downstream user to access is fair game for them to use. You can certainly mark it as internal and be explicit that you reserve the right to break it later, but if it's actually possible for users to do, it's not "improper", even if it gets broken later.
  - kaba0 3y ago
    That's why they sealed those holes shut, and only allow some of them with deliberate end-user command-line flags, so that anyone wanting to go that way only has themselves to blame.
- nvm0n2 3y ago
  No there were lots of just outright breaks. JavaEE being removed, along with a package frequently used for Base64 encoding (with no replacement until several later versions). JavaFX being separated out so it's not bundled anymore, along with removing javafxpackager (since returned as jpackage). Java Web Start being removed. Then there were all the borderline stuff. The locations of files inside the JDK all changing, like "rt.jar" went away and a lot of tools depended on that. The concept of an installable JRE was removed entirely and along with it the whole way people were used to distributing Java apps was deprecated with no replacement until much later (and the replacement was much worse in some ways). Suddenly spamming warnings to the console if you use widely used packages (which breaks anything parsing the output). Even just changing the version number broke a lot of stuff because code had been written to assume the convention that Java version numbers started with "1." Then when they went to 6 month releases soon after, that broke a lot of stuff because the whole ecosystem made the design assumption that Java releases were rare (stupid stuff like using enums to represent versions, the Java guys bump the version number in .class files on every release even if nothing changes). Then people tried to use the new module system, but that broke the world too and for little/no ROI, so eventually everyone gave up. Now the ecosystem is full of broken module metadata that's there but doesn't work, and if you try to use it and report bugs they get closed with status: "don't care". Frankly a lot of the dust has still never settled, it was a very damaging time for the Java community. Backwards compatibility über alles bitte, and that means NOT removing widely used features that were heavily developed and advertised as the right way to do things for decades.
  - kaba0 3y ago
    I only see eternal stagnation as the alternative, and surely noone wants that. Java does have very good backwards compatibility and they make every change with that in mind, but if you are big enough, no matter what you do, someone will surely depend on some stupid thing they should have never do in the first place.
valenterry 3y ago
Well, they removed code that was always discouraged from using and it was always and explicitly stated, that there are no guarantees of any kind when using this code. The code was not living in a package called "unsafe" and being undocumented (to my knowledge) by coincidence. So while Java broke some big libraries/frameworks (not "pretty much everything though"), it can't really be blamed on them. In fact, look what Go has: https://pkg.go.dev/unsafe https://pkg.go.dev/unsafe > Package unsafe contains operations that step around the type safety of Go programs. > Packages that import unsafe may be non-portable and are not protected by the Go 1 compatibility guidelines. Let's wait until Go has reached Java's maturity and see what happens when they change this package ;)
- jerf 3y ago
  "Let's wait until Go has reached Java's maturity and see what happens when they change this package ;)" They did a while back, actually. Compare https://pkg.go.dev/unsafe@go1.0.1#Pointer https://pkg.go.dev/unsafe@go1.0.1#Pointer with https://pkg.go.dev/unsafe#Pointer https://pkg.go.dev/unsafe#Pointer , in particular the modern very precise description of exactly what you can do with an *unsafe.Pointer. I'm not sure what the cutoff for that was but it was a while ago, yes. Still, it didn't do much.
  - valenterry 3y ago
    Interesting! Personally I'm not a big fan of either Java nor excessive backwards compatibility. But I can't avoid noticing that a lot of people praise Go for things like the backwards compatible while despising Java at the same time, even though both languages are extremely similar in lots of regards.
    - geodel 3y ago
      It is not clear that people despise Java or they despise backward compatibility of Java. Because I haven't see anyone despising Java's backward compatibility.
      - 3y ago
kaba0 3y ago
If that's pretty much everything, then nothing is backwards compatible unless they have the same hash..
pjmlp 3y ago
One cannot make omelette without breaking a couple of eggs.
morepork 3y ago
I was pleasantly surprised about 6 months ago when I went to run a game I wrote in Java when I was at university. Nothing huge, but still about 10k lines of code. I originally wrote it in Java 6, and it compiled and ran with no issues on Java 20. I only used one 3p lib, otherwise just the standard library, which helped, but I was expecting something to be broken given it was over 10 years later.

Ironically they then went ahead and made a massive change in Java 9 that, for the first time in Java's history, broke pretty much everything. Still angry about that...

szundi 3y ago

Was it more than internal lib references that one was not supposed to do anyway?

cogman10 3y ago
Pretty much. Most of the breaks came from touching the likes of "sun.misc.Unsafe". Java versions 9->~17 added new jdk features (such as VarHandles) to allow for the safe interactions that sun.misc.Unsafe exposed. Libs had to update to use these new patterns with 9 being the worst hurdle. There was also a change to how packages could be named that messed with stuff. 2 jars putting stuff into stuff like `javax.annotations` was a big no-no that broke with 9.

MichaelNolan 3y ago

Hopefully there should never be a repeat of that now that they have strongly encapsulated jdk internals. My understanding is that (nearly) all of the migration headaches from 8 to 9 were caused by libraries that were using improperly using jdk internals.

saghm 3y ago
Devil's advocate: anything that's possible for a downstream user to access is fair game for them to use. You can certainly mark it as internal and be explicit that you reserve the right to break it later, but if it's actually possible for users to do, it's not "improper", even if it gets broken later.
- kaba0 3y ago
  That's why they sealed those holes shut, and only allow some of them with deliberate end-user command-line flags, so that anyone wanting to go that way only has themselves to blame.
nvm0n2 3y ago
No there were lots of just outright breaks. JavaEE being removed, along with a package frequently used for Base64 encoding (with no replacement until several later versions). JavaFX being separated out so it's not bundled anymore, along with removing javafxpackager (since returned as jpackage). Java Web Start being removed. Then there were all the borderline stuff. The locations of files inside the JDK all changing, like "rt.jar" went away and a lot of tools depended on that. The concept of an installable JRE was removed entirely and along with it the whole way people were used to distributing Java apps was deprecated with no replacement until much later (and the replacement was much worse in some ways). Suddenly spamming warnings to the console if you use widely used packages (which breaks anything parsing the output). Even just changing the version number broke a lot of stuff because code had been written to assume the convention that Java version numbers started with "1." Then when they went to 6 month releases soon after, that broke a lot of stuff because the whole ecosystem made the design assumption that Java releases were rare (stupid stuff like using enums to represent versions, the Java guys bump the version number in .class files on every release even if nothing changes). Then people tried to use the new module system, but that broke the world too and for little/no ROI, so eventually everyone gave up. Now the ecosystem is full of broken module metadata that's there but doesn't work, and if you try to use it and report bugs they get closed with status: "don't care". Frankly a lot of the dust has still never settled, it was a very damaging time for the Java community. Backwards compatibility über alles bitte, and that means NOT removing widely used features that were heavily developed and advertised as the right way to do things for decades.
- kaba0 3y ago
  I only see eternal stagnation as the alternative, and surely noone wants that. Java does have very good backwards compatibility and they make every change with that in mind, but if you are big enough, no matter what you do, someone will surely depend on some stupid thing they should have never do in the first place.

valenterry 3y ago

Well, they removed code that was always discouraged from using and it was always and explicitly stated, that there are no guarantees of any kind when using this code. The code was not living in a package called "unsafe" and being undocumented (to my knowledge) by coincidence. So while Java broke some big libraries/frameworks (not "pretty much everything though"), it can't really be blamed on them. In fact, look what Go has: https://pkg.go.dev/unsafe https://pkg.go.dev/unsafe > Package unsafe contains operations that step around the type safety of Go programs. > Packages that import unsafe may be non-portable and are not protected by the Go 1 compatibility guidelines. Let's wait until Go has reached Java's maturity and see what happens when they change this package ;)

jerf 3y ago
"Let's wait until Go has reached Java's maturity and see what happens when they change this package ;)" They did a while back, actually. Compare https://pkg.go.dev/unsafe@go1.0.1#Pointer https://pkg.go.dev/unsafe@go1.0.1#Pointer with https://pkg.go.dev/unsafe#Pointer https://pkg.go.dev/unsafe#Pointer , in particular the modern very precise description of exactly what you can do with an *unsafe.Pointer. I'm not sure what the cutoff for that was but it was a while ago, yes. Still, it didn't do much.
- valenterry 3y ago
  Interesting! Personally I'm not a big fan of either Java nor excessive backwards compatibility. But I can't avoid noticing that a lot of people praise Go for things like the backwards compatible while despising Java at the same time, even though both languages are extremely similar in lots of regards.
  - geodel 3y ago
    It is not clear that people despise Java or they despise backward compatibility of Java. Because I haven't see anyone despising Java's backward compatibility.
    - 3y ago

kaba0 3y ago

If that's pretty much everything, then nothing is backwards compatible unless they have the same hash..

pjmlp 3y ago

One cannot make omelette without breaking a couple of eggs.

morepork 3y ago

I was pleasantly surprised about 6 months ago when I went to run a game I wrote in Java when I was at university. Nothing huge, but still about 10k lines of code. I originally wrote it in Java 6, and it compiled and ran with no issues on Java 20. I only used one 3p lib, otherwise just the standard library, which helped, but I was expecting something to be broken given it was over 10 years later.