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.



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 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 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.



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s