6 ms·

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 compatibi

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.

mrweasel 3y ago
I did not know that was the reasoning or logic behind the Java 8, 9, 10 ... numbering, that clears up so many thing.
- twic 3y ago
  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.
  - hbn 3y ago
    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.
    - chipotle_coyote 3y ago
      I’d argue that the “everything is 10.x” for Mac OS was also basically marketing. :)
adrianmsmith 3y ago
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.
blackoil 3y ago
This happened at Java SE 5(1.5) after 1.4. This was at much a marketing decision.
- cogman10 3y ago
  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).
- minutillo 3y ago
  It goes back ever further, Java 1.2 was marketed by Sun as "Java 2". https://web.archive.org/web/19991010063140/http://java.sun.com/events/jbe/98/features/launch.html https://web.archive.org/web/19991010063140/http://java.sun.c...
cpeterso 3y ago
Sun did the same for Solaris, jumping from version 2.6 to 7: https://en.wikipedia.org/wiki/Oracle_Solaris#Version_history https://en.wikipedia.org/wiki/Oracle_Solaris#Version_history

mrweasel 3y ago

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

twic 3y ago
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.
- hbn 3y ago
  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.
  - chipotle_coyote 3y ago
    I’d argue that the “everything is 10.x” for Mac OS was also basically marketing. :)

adrianmsmith 3y ago

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.

blackoil 3y ago

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

cogman10 3y ago
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).
minutillo 3y ago
It goes back ever further, Java 1.2 was marketed by Sun as "Java 2". https://web.archive.org/web/19991010063140/http://java.sun.com/events/jbe/98/features/launch.html https://web.archive.org/web/19991010063140/http://java.sun.c...

cpeterso 3y ago

Sun did the same for Solaris, jumping from version 2.6 to 7: https://en.wikipedia.org/wiki/Oracle_Solaris#Version_history https://en.wikipedia.org/wiki/Oracle_Solaris#Version_history