I always wondered what in the world the Sun marketing guys were thinking. They kept changing the real name of the JDK. Starting with JDK 1.2, they decided that they wanted to call it "Java 2", and the "Java 2 Platform". But developers still downloaded JDK 1.2. OK, that makes some sense, I guess. Then, when JDK 1.3 came out, it was still "Java 2 Platform". If there was any logic, it would now be the "Java 3 Platform". Well, OK, so now it's Java 2 forever. Then, when JDK 1.5 appeared, it became Java 5. Now they are clearly just making this stuff as they go. Now, the current thinking is that it's just the "Java Platform", and "Java Enterprise Edition" (to avoid the charming "JPEE" acronym). What in the world is going to have to happen for the real version number to trip up to 2.0. And why the reluctance? Is there something magical about version 2.0? Why didn't the marketing and technical guys just get together when JDK 1.2 came out and call it "Java 2" then? It's not like they're going to run out of numbers -- there are literally an infinite number of them!
Without realizing it, the technical guys didn't think (and apparently still don't) that Java was good enough for a real Version 2. They've been waiting...and now it's here. Groovy is the REAL Java 2. Henceforth, we can think of the Java language (not the platform) as forever 1.x. Groovy is what the real second version of Java should have been. The technical guys must have felt it their guts all along.
I've heard some rumors about wacky version numbers for Groovy. It leapt from 1.1 to 1.5. Stop it! When you make changes to it, increment the bloody first number! Unless you want someone in a decade writing a smarmy piece about how your technical marvel just got supplanted, and that it was a version 1.x technology all along.
Subscribe to:
Post Comments (Atom)
7 comments:
It could be worse: Oracle middleware uses a 5 dotted together numbers (e.g., 10.1.3.4.1), each corresponding to some piece of the tech stack.
"When you make changes to it, increment the bloody first number!"
It's meanlingless to compare version numbers of unrelated products.
Version numbers communicate important information about how changes TO A SINGLE PRODUCT affect backward compatability. A major number increment indicates a break with backward compatability. A minor number increment indicates additional functionality.
Nat, I understand the concept, but it's flawed to the core. What happens if you have more than 10 minor changes, like Java is rapidly approaching? And, you have marketing arbitrarily changing the name, which is at least as identified as the version number. Of course, as the previous commenter said, you could switch to some IP address-looking version numbering scheme. Notice that, in full-blown pundit mode, I'm just casting stones at something annoying, without proposing a reasonable solution!
What happens if you have more than 10 minor changes,
Why, you go from 1.9 to 1.10. Was that a trick question?
like Java is rapidly approaching?
Rapidly? Where is 1.7?
Anyway, one of the few programs whose version is a floating point number is TeX.
And Sun is used to strange version numbering. SunOS n.x was Solaris (n-3).x.
Yes, it was a trick question. Blog comment humor is tough because it's such a low-bandwidth communication channel.
Having the version number perpetually at 1.x is just noise -- the leading 1 ceases to have meaning.
This is why I stopped putting version numbers in my resume a while ago. I leave this up to my interviewer to figure out which version I am actually familiar with. As for Groovy being the real Java 2, well... it sure does break backward compatibility! :)
Given that there are still people who'd use floats instead of decimal classes, be forewarned that 1.6000000000000001 != 1.6
Post a Comment