When it comes to the question of “what JDK does your application runs on”, my answer “JDK 1.2.2” usually causes a lot of raised eyebrows, along with questions like “That’s pretty old? Why don’t you update? There are so many new features in the new !”

Well, until now I haven’t found a feature that was compelling enough to upgrade.

“Perfection is achieved, not when there is nothing more to add, but when there is nothing left.”

Starting with JDK 1.3, Sun wend on a strange and weird expedition with its JDK.

The classes in the JDK define the core functionality set of the Java Language. In the old days of JDK 1.2.2, this core feature set was a sensible minimum for working with Java. Anything beyond that functionality would have to be added as extension-library or application-library (the difference between the two choices is minimal; extensions are managed by the boot-classloader, are always trusted and always available to all applications. Extensions are added by copying the JARs into the $JRE/lib/ext directlry. Application libraries are untrusted by default, are application specific and are therefore only loaded if specified on the classpath. There is no limitation in what functionality you can achieve in either way, its just “do you have to set the classpath or not”.

In JDK 1.3 Sun started to copy JNDI and a Corba-ORB into the JDK. Before that, JNDI was a separate extension library, while the ORB was a external product. So there was no reason, other than feeling the need to have some new features, to pump up the size of the JDK.

The reasoning for the Corba-ORB is particulary funny. From the README: “This eliminates the requirement for licensing and distributing third-party Java ORBs.” The last time Microsoft tried that reasoning, they got sued to the ground. Well, Sun could as well just have made that ORB available under a free (as in beer, I dont want to be so demanding to ask for “as in speech”-freedom yet) license with the same effect. But (I guess) CORBA was  what all the “cool kids” used at that time, so the JDK would have to follow.

I yet have to see Corba-based applications outside the scope of heavy enterprise applications (which normally use the Enterprise Editon of the JDK anyway)

With JDK 1.4, Sun started to mess around with the language specs (and never stopped since then). The formerly extension libraries JAXP and Java-ImageIO were added to the JDK. Looking at the very sucessful open-source market, Sun also added a Logging API (which is a cheap and horrible to configure copy of Log4J), regular expressions (ignoring the fact that there are plenty of well-established RegExp-libraries available), a new Printing-API and a preferences API.

Again, most of these libraries existed as separate projects before, and none of these libraries requires special attention from the JDK to run. So there is absolutely no reason for them to be a core functionality.

The printing API is not that bad, but there was and is no reason for that being a core functionality. The API could have been created as a ordinary JDK-extension, and thus not adding a megabyte or two to the JDK. As JNDI failed to get acceptance from the users, Sun tried again, and added a Preferences-API. Giving developers a sensible API for storing application preferences is a good thing, no question. But that whole API smells just like a simplified version of the JNDI system. So instead of providing a sensible JDNI default implementation, they prefered to add something new. Sweet, more space wasted.

Then there was JDK 1.5 (or 5.0, as Dot-Net was approaching, and so Sun had to show that Java was more mature. Sooner or later we will see a “Java XP”, I guess. For the first time, Sun did not add new libraries (updating previously added libraries does not count as something new, despite all marketing claims), yet still managed to mess around with the language to introduce a new layer of possible bug-injection points.

But heaven did not last long. JDK 1.6, (I guess after running out of libraries to add without looking stupid,) now ships with a whole database system. Embedded databases are perfectly suited for desktop applications, sure, but for ages they roamed freely through forrests and over plains, and people used them like any other library. So what’s the point in adding yet another 20MB of Jars to the already huge JDK? What makes this move even more ridiculous: Java-DB is not even part of the JDK 1.6, it is installed in a separate location and has to be activated manually. For now, the JRE also does not ship with that database – but you can bet it will later!

I really wonder – what’s the reasoning behind that? Do they want to copy each aspect of Dot-NET (including the 5GB runtime called “a Windows installation”)? Or is this just a “I’ll scratch your back” move towards IBM (which orignally developed Java-DB (aka Derby, aka DB/2-Embedded)?

So make the insanity obvious, just look at the numbers:

JDK 1.2.2_17; Windows; International Version: 7.18 MB
JDK 1.3.1_20; Windows; International Version: 7.94 MB
JDk 1.4.2_16; Windows; Multilingual Version: 14.94 MB
JDk 1.5.0_14; Windows; Multilingual Version: 16.10 MB
JDK 1.6.0_5; Windows; Multilingual Version:  15.18 MB

The next JDK (JDK 1.6.0-update 10), finally tries some corrective steps. The JDK will no longer install all bloated core packages; most packages will now be downloaded and installed on demand (Which will give a funny new class of ClassLoader-errors (“HTTP 404: Class not found”).

“The JRE is being modularized, so that bits and pieces of it can be downloaded as needed. In the current prototype, the download needed to support a typical Swing program is between 3 and 4MB.”

At that point, we will be back where we started, at the size of JDK 1.2.2. Sanity wins, finally.