When it was announced that Doug Lea's concurrent library was being added to the core set of Java classes, I had a classic movie moment:

A typical corporate development environment: cubicles with high walls, drab grey color, and harsh artificial lighting. A developer is seen happily working at his workstation. A small message appears on the screen. All that is seen is the message:

Doug Lea's concurrent library brought into the JDK

The programmer's typing has stopped and a loud thump is heard. The scene quickly shifts back from the screen to show the developer's head on the desk. The scene continues to move back and upward.

DEVELOPER

Noooooo!

The programmer's hands move up to his head as he lifts his head, leans back and continues the cry. Fade to black.

Why do I want that wonderful utility brought into one of the slowest revisioning software products of the modern era? Currently, if there's a problem with the concurrent library, I post a bug, Mr. Lea takes a look at it within a few days (a week if he's on vacation) and shortly thereafter there is a patch. Constrast this with what occurs now in the JDK: file a bug, get a cryptic response (if any) in bug parade, wait patiently for months if not years for bug parade updates, con anyone you know into voting for the bug at any chance they get, then, if the phase of the moon is just right with the angle of Mercury to the ecliptic, the bug will be listed as fixed in some version that is at least two versions ahead of the currently released JDK or in some obscure version, and finally, once the JDK version has finally come out, you download and test only to find out that something was broken because of the fix.

It was recently rumored that RFE's are being accepted and voted on for Java 1.6. There are dozens of additions that people are looking for in the JDK. Why do I need javax.swing or java.awt in my server application? Why do I need java.sql in my game? Why does anyone need org.omg.CORBA *grin*?

My RFE is this: remove everything from the JDK! Reduce "Java" down to java.lang.* (and possibly java.security). All other packages will be divided into separate projects and made open source. Sun will retain control over "Java the language". To the end developer, Java will appear unchanged.

In order to support the current uses of Java, the profiles paradigm (seen with embedded Java, for example) would be used. For example, there would be an applets profile and a server-side (J2EE) profile. Each profile will define the necessary packages and versions. To facilitate this, a robust jar versioning mechanism would be required. This would also benefit anyone that has ever had to deal with jar version hell. A first pass might be to use Package. Strict guidelines would need to be published to define how versions are numbered and updated. Sun can provide a test and certification process whereby versions are validated and signed.

There are going to be a number of snafu's that need to be rectified. For example, the current NIO implementation uses a trick in java.lang.Thread (look for blockedOn()) in order to handle some of its interruptable aspects (such as InterruptableChannel). The JDK provides an SPI to allow vendors to create their own NIO implementation, but given tricks like these, it's impossible for anyone but Sun to do. Separating java.lang from the other packages will force these issues to light and force them to be resolved. In this case, one can envision a java.lang.Interruptable, for example.

There might be a concern that this idea will cause there to be 400 java.util versions out there. To this I say: are there 400 versions of apache commons? The concurrent library? I will admit that back when Java first arrived on the scene, there was a bit of chaos. That has, for the most part, settled down and there are well understood and respected methods to producing open source software versions.

Another concern would be intra-package reuse. For example, the java.util maintainers prefer log4j whereas the java.io maintainers prefer the current Java logging API. I don't claim to have an easy answer for this but certainly a product management committee could be assembled where each package is represented. This committee would be responsible for coordinating and resolving issues such as this.

How does JSR fit into all of this? I honestly don't know. I suppose that it will do what it has always done but rather than have most of its results put into the JDK, they will become an open source project.

Kris brings up a number of reasons that dealing with the current JDK bloat is not easy.