Java Versioning – Why Java Version 1.X is Referred to as Java X

historyjavaproduct-namesversioning

I saw that Java 1.2 is also known as Java 2. Do "Java 1.x" and "Java x" (for example "Java 1.6" and "Java 6") refer to the same version of Java?

And if yes, why the need for this duality?

Best Answer

Sun Microsystems had back then a bad habit of going through numerous naming changes for its products, and to use confusing name to start with in the first place.

What's in a Name, or what does "Java" Mean?

Originally the term "Java" was being used to describe indiscriminately:

the language,
the platform,
and some others happened to refer to the JVM and the Java Class Lib as just Java as well.

Internal and External Number

With regard to version numbers, as others pointed out it was partly because of marketing, and partly because they simply felt like Java had done such progress a major version upgrade was better suited (for Java 1.2 / Java 2, and when Java 1.5 / Java 5).

So, what we call Java 2 was actually Java 1.2 to 1.4. Java 3 and Java 4 never existed, and we skipped directly to Java 5, as they tried to explain here (from this page on naming and versioning).

I was also probably a little as well to not mess with their internal numbering used in their tracking and development systems. I tend to think of it as 1.x = language version and X = language and product version. It makes sense, as normal users do not need to worry about minor increments and updates, as they encourage automatic updates, and these shouldn't introduce any changes to the language or the bytecode.

Note also that it gets weirder when you look at minor versions and update numbers. For instance, we had a Java 1.3.1 and later Java 1.4.1 and 1.4.2.

Updates

However, there were no 1.x.y ever since, it's always been 1.x.0_UPDATE:

Java 5 had updates up to 1.5.0_22,
Java 6 is - so far - up to 1.6.0_37,
Java 7 is - so far - up to 1.7.0_09.

Note also that you will also see updates refered to with either of these naming conventions:

like 1.5.0_22 or 1.7.0_04 (note the padding 0s on the update version, aligning on 2 digits),
but also 1.5.0u22 or 1.7.0u4 (note the padding 0s are gone, yay!).

And for extra confusion and to keep up with Sun Microsystems' tradition, Oracle now drops announcements like this.

Product Names

Note also that not only did they get into the habit of changing the numbering, but also the names of the product offerings. So, Java 2 have J2SE (Java 2 Standard Edition), J2EE (Java 2 Enterprise Edition) and J2ME (Java 2 Mobile Edition). Since the introduction of Java 5, these conventions and acronyms have been dropped (though some have an incredibly long resilience, mostly thanks for dumb recruitment agencies who have no clue what they are talking about) in favor of Java SE, Java EE and Java ME, which are sometimes abbreviated - but shouldn't officially - to JSE, JEE (fairly common) and JME.

Your read this page for more information about the current versioning system used by Sun Microsystems and now Oracle since Java 1.3.1.

(For bonus points, try to lookup the history of NetBeans now to see that it was also renamed a few times).

They Don't Know Themselves

They're also struggling to decide whether they should back-update existing references or not. For instance, this page about older releases uses the old numbering system for old releases, but the newer product names (Java SE 1.1, 1.2, 1.3 and 1.4 were not released with this naming convention).

Maybe they're just screwing with us for fun. Who knows?

What About the JVMS and JLS?

They had fun with naming and numbering there too, of course.

The Java Language Specification used to be released with a book "edition" versioning syste,, following product numbers. So:

Java 1 had its "Java Language Specification",
Java 2 had its "Java Language Specification, 2nd edition".

So far, so good.

Except the "Java Language Specification" was later only re-edited when language changes were introduced in Java 5 (which kind of make sense, you won't publish new book editions just for fun). As this was the 3rd time they were editing it, they called it (tada!) "Java Langauge Specification, 3rd edition".

But obviously, people then started to wonder why 1.3 and 1.4 didn't have a language spec, or why Java 5 was matched with a 3rd edition of the language spec.

So, Java 7 is now just calling it the "Java Language Specification, Java SE 7 Edition", though we often refer to this one as JLS7 for shorthand and to avoid RSI.

They're Not the Only Ones...

For additional fun, look at Microsoft Windows RT's naming fail, or Apple's naming and numbering madness with iPhones, iPads or even iPods.

Related Solutions

Java History – Core API Packages of Java 1.0

Per Wikipedia, the first formally released version of Java was 1.0.2, on Jan 23 1996.

The first stable version was the JDK 1.0.2. is called Java 1

There's an archive of Java 1.0.2 and all related documentation here:

JDK 1.0.2 API reference (book format)

JDK 1.0.2 API reference (javadoc format)

Java tutorial

Java language specification (link broken, wayback'd here)

Java virtual machine specification

There appears to be a download of the JDK 1.0.2 bits here

http://www.pascal-man.com/download/download-jdk.shtml

It works for me at the time of writing.

Java 1.0.2 on Windows 7 x64

BEHOLD THE RAW UNMITIGATED POWER OF JAVA 1.0.2

In the language spec, the following classes are referred to (single citation, not exhaustive citations):

Class (section 4.3.1)
String (section 4.3.1)
Object (section 4.3.2)
Random (section 4.4)
Thread (section 17.2)
ThreadGroup (section 17.2)
Throwable (section 11)
Error (section 11.2)
loads and loads of errors, all under java.lang (section 11.5.2.1 - 11.5.2.2)
RuntimeException (section 11.2.1)
the "Array classes", [I, and so on (section 10.8)

... at which point I stopped looking because, technically, [I, et. al. aren't in the java.lang, java.util, or java.io packages.

Example:

class Test {
  // Compare namespaces of built-ins object and int[]
  public static void main(String[] args){
    int[] arr = new int[0];
    Object obj = new Object();

    Class arrClass = arr.getClass();
    Class objClass = obj.getClass();

    Class arrSuper = arrClass.getSuperclass();

    System.out.println("plain jane Object - " + objClass.getName());
    System.out.println();
    System.out.println("int[] - "+arrClass.getName());
    System.out.println("super of int[] - "+arrSuper.getName());
  }
}

Outputs

enter image description here

Behavior is consistent between modern and 1.0.2

enter image description here

Java – Why doesn’t Java String have static string manipulation methods

The returning of null makes sense to me since manipulating a null string should result in a null string, not an error

Well, that is your opinion. Others may argument that String operations on a null object, which does not contain a String, make no sense and hence should throw an Exception

Why "Java designers" did or did not something is difficult to anwer.

There are already libraries out there which can do null-safe String operations, e.g. StringUtils of Apache Commons. You can use that or similar libraries if you need them.

Addition based on your comments

Reading through the comments, it seems like the real problem you face is that you have to check for null all over your code. That can be an indicator of a bad program design without clearly defined contracts between interfaces. You might want to read Avoiding “!= null” statements in Java?