3 ms·
In Java people regularly refer to a particular JDK version as a Java 17 or Java 11, even though they actually refer to versions 1.17 and 1.11, respectively[0].
by robto 5y ago
In Java people regularly refer to a particular JDK version as a Java 17 or Java 11, even though they actually refer to versions 1.17 and 1.11, respectively[0]. In Clojure land they just say 1.x, even when large new features are added.
I like this because it emphasizes the community's commitment backwards compatibility, which I greatly value. I've spent a good deal of time writing Javascript, where library developers seem to have very little respect for their users and constantly break backwards compatibility. In ecosystems like that, upgrading fills me with dread. When I see a library on version 4, I have learned to keep looking - if they weren't thoughtful enough about their API design for the first 3 major releases, I shouldn't expect it to be much better going forwards.
For an application, I'm pretty open to version numbers signifying big features - Firefox and Chrome do this, and it's helpful with marketing. But for a programming language? A programming language is a tool, and when upgrading you need to carefully read the changelog anyways. A programming language is no different from a library (in Clojure it literally is a library), and backwards compatibility is /literally/ the main thing I care about. Is my tool going to intrude on /my/ schedule, and force me to make changes /it/ wants instead of being able to spend my time making changes /I/ care about? I want to know that.
[0]This is apparently an awful example as I've just learned that Java is actually doing the major version only thing. It still sort of works because the only reason they can do that is because they Will Not Break Compatiblity.
- linkdd 5y ago> In Java people regularly refer to a particular JDK version as a Java 17 or Java 11, even though they actually refer to versions 1.17 and 1.8, respectively. 17 -> 1.17, 11 -> 1.8, this is bothering me way to much for no good reason.
- danudey 5y agoClarification: * Java 8 is Java 1.8.0 * Java 11 is Java 11.0.11 (at the moment) * Java 17 is Java 17.0.1 (at the moment) SunOS/Solaris is what I use when I want to get nerd-rage mad about minutae: https://en.wikipedia.org/wiki/Oracle_Solaris#Version_history https://en.wikipedia.org/wiki/Oracle_Solaris#Version_history
- post-it 5y agoI don't think 11 ever referred to 1.8 generally, but for the longest time the `openjdk-11-*` packages in one of the Ubuntu LTSes (18.04?) actually installed Java 8 for some reason.
- deleted 5y ago[deleted]
- pjmlp 5y agoJava does break compatibility, although they strive to avoid it as much as possible. https://docs.oracle.com/en/java/javase/17/language/java-language-changes.html https://docs.oracle.com/en/java/javase/17/language/java-lang... https://docs.oracle.com/en/java/javase/17/migrate/getting-started.html https://docs.oracle.com/en/java/javase/17/migrate/getting-st... The x.y versioning with y being a synonym for major version was abandonend in Java 9.