Hacker News Reader

Comment by cogman10 | Hacker News Reader

Java went through this. There was a Java 1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, and 1.7. Then, Java decided "You know what, we aren't breaking backwards compatibility so instead of naming things 1.x, let's just say Java 8, 9, 10...21"

I think that ultimately makes sense.

View on HN

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

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

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.

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.

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.

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.

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.

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.

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

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

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

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.

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.

> Because I haven't see anyone despising Java's backward compatibility.

I'm happy to have beers, just so that you get the chance to see someone like that. :-)

> So while Java broke some big libraries/frameworks (not "pretty much everything though"), it can't really be blamed on them.

I think one of the reasons people use Java is to get access to those big libraries/frameworks.

I've worked at a few companies that used Java during the transition, so maybe I had access to about 10 Git repos that underwent this transition.

I think pretty much all of them required some tweaking e.g. adding extra dependencies in Maven when moving from Java 8 to Java 11. I actually became the "go to" person to do these transitions, having worked out what incantations were needed.

All of those repos, to this day, despite the effort that was put into them during the transition, now print out warnings about things being unsafe. The companies just ignore those warnings. I have 15 years of Java experience and I don't know what to do about them. My understanding is this is normal in the Java world now.

They are just normal web applications or REST services using databases like PostgreSQL, using e.g. Spring Boot, Tomcat, etc. Maybe those libraries do things they're not supposed to, I don't know. I have never used sun.misc.Unsafe in my code or anything like that.

Perhaps if I spent days studying the problem I could understand what was going on and what to do about it (although probably not, as the problems might have been in third-party dependencies.) But this wasn't money the companies I worked for wanted to spend. But anyway, my point is that spending days fixing stuff after an upgrade != backwards compatible.

You likely has a dependency of dependency of a dependency that uses it, and thus get the warning.

Heh, once there is spring boot as dependency it has like 100 library jars to show hello world on web page. So pretty much sure everything would be broken.

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

One cannot make omelette without breaking a couple of eggs.

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.

Sun did the same for Solaris, jumping from version 2.6 to 7:

https://en.wikipedia.org/wiki/Oracle_Solaris#Version_history

I did not know that was the reasoning or logic behind the Java 8, 9, 10 ... numbering, that clears up so many thing.

Also relevant is that Sun had pulled the same trick with Solaris a few years earlier - Solaris 2.6 was followed by Solaris 7. Bigger version numbers make for better marketing. I am skeptical that backwards compatibility was strongly involved.

Apple also did a similar thing with OSX/macOS a few years ago - instead of making everything 10.XX they bump the major version (first number) every year now, continuing on from the 10 that the X represented, as if each version is the same increment as the jump from Mac OS 9 to Mac OS X (which was a jump to an entirely new codebase)

Android did that too, much earlier starting with 5.0. Previously the major version was something of an indicator of a major visual/conceptual redesign. 3.0 was the tablet version, 4.0 was the move to the holo design language, 5.0 was material. Then they just kept bumping the major version every year since.

I also assume it's just for marketing reasons.

I’d argue that the “everything is 10.x” for Mac OS was also basically marketing. :)

This happened at Java SE 5(1.5) after 1.4. This was at much a marketing decision.

That was somewhat different from the way the internal stuff was numbered. You'd still see "1.5" and "1.6" everywhere when you asked the JVM for it's version. 8 was when the JVM started matching the marketing (IIRC, might have been 9).

It goes back ever further, Java 1.2 was marketed by Sun as "Java 2".

https://web.archive.org/web/19991010063140/http://java.sun.c...

Reply on news.ycombinator.com