Open Source vs JDK Bloat

One of my long-running annoyances with the Sun Java Development Kit (JDK) has been the "bloat" that each excessive JDK has added. I don't really care about megabytes but I do care about code, and each JVM has added more and more functionality, often conflicting with existing open source packages.

Here's my problem: Sun controls what goes into the JDK through the J2SE JCP process. And Sun has added more and more packages into the JDK while making minimal changes to the JVM and core language. And in my mind, this is completely the opposite to what should be done. A simple example is script language support.

For years, there has been a completely portable way of adding scripting language support into Java using Apache BSF. Sun added scripting support to JDK6 and broke a whole bunch of existing BSF applications. BSF not only worked, but it also had a more permissive license than the JDK and is completely portable back to ancient versions of the JDK, meaning that you have much portability. The same applies to StAX, JAXB, JAXWS, and a whole lot more. In the case of StAX, its probably worse, because the Codehaus Woodstox project is far better than the one Sun ships.

In fact, it almost seems like the JCP has gone out of its way to find good Open Source projects, and then take the exact same function and replicate it then add it to the JDK. In some cases, Sun has worked with the community - the java.util.concurrent code is a good example. But even in these cases, many people had to rely on the backport code because they wanted to run on JDK 1.4.

Meanwhile, the core language has creeped along. It took a long time for generics to arrive, and it will be a long time before I can use closures - by the time my users are all on the right JVM I'll probably be retiring!!

Anyway, enough moaning! What is the solution? Sameera, one of the WSO2 team has pointed out that under OSGi you can control which packages from the JDK are exposed to your code. Now I can have complete control and if I want to use Open Source equivalents I can. Even better, I can protect against future JDK revisions by strictly controlling which packages are exported.

Update:
Sameera has blogged this:
http://tech.jayasoma.org/2009/04/exporting-public-jdk-packages-in-osgi.html

http://tech.jayasoma.org/2009/04/exporting-public-jdk-packages-in-osgi-2.html

You simply need to set the

org.osgi.framework.system.packages

system property.

If you want to see the packages exported by default, pull up your OSGI command line:

java -jar org.eclipse.osgi_3.4.0.jar -console

getprop org.osgi.framework.system.packages

If you want a simple example of the bloat here is the difference between 1.5 and 1.6. As far as I know, the annotations are the only real "core language" change and all the rest of the code is also available in Apache or BSD licensed Open Source code.

> javax.activation
> javax.annotation
> javax.annotation.processing
> javax.jws
> javax.jws.soap
> javax.lang.model
> javax.lang.model.element
> javax.lang.model.type
> javax.lang.model.util
> javax.script
> javax.tools
> javax.xml.bind
> javax.xml.bind.annotation
> javax.xml.bind.annotation.adapters
> javax.xml.bind.attachment
> javax.xml.bind.helpers
> javax.xml.bind.util
> javax.xml.crypto
> javax.xml.crypto.dom
> javax.xml.crypto.dsig
> javax.xml.crypto.dsig.dom
> javax.xml.crypto.dsig.keyinfo
> javax.xml.crypto.dsig.spec
> javax.xml.soap
> javax.xml.stream
> javax.xml.stream.events
> javax.xml.stream.util
> javax.xml.transform.stax
> javax.xml.ws
> javax.xml.ws.handler
> javax.xml.ws.handler.soap
> javax.xml.ws.http
> javax.xml.ws.soap
> javax.xml.ws.spi