The Massive, Monolithic JDK should become Modular

Mark Reinhold, Principal Engineer at Sun Microsystems, has been advocating about how “cool” would be for the Sun JDK to be modular. He’s is putting up a good argument about how the complexity is hurting the platform and how the Java Kernel and Quickstarter  features in the JDK 6u10  release just address the symptoms of JDK’s long-term interconnected growth.

Mark starts-off by explaining how we got to the current state of having such a huge JDK:

The JDK is big, too-though not (yet) as big as space.

It’s big because over the last thirteen years the Java SE platform has grown from a small system originally intended for embedded devices into a rich collection of libraries serving a wide variety of needs across a broad range of environments.

It’s incredibly handy to have such a large and capable Swiss-Army knife at one’s disposal, but size is not without its costs.

He continues by explaining the disadvantages that come from this:

The JDK is big—and it’s also deeply interconnected. It has been built, on the whole, as a monolithic software system. In this mode of development it’s completely natural to take advantage of other parts of the platform when writing new code or even just improving old code, relying upon the flexible linking mechanism of the Java virtual machine to make it all work at runtime.

Over the years, however, this style of development can lead to unexpected connections between APIs—and between their implementations—leading in turn to increased startup time and memory footprint. A trivial command-line “Hello, world!” program, e.g., now loads and initializes over 300 separate classes, taking around 100ms on a recent desktop machine despite yet more heroic engineering efforts such as class-data sharing. The situation is even worse, of course, for larger applications.

Mark doesn’t seem to think that the Java Kernel and Quickstarter  features in the JDK 6u10  release, are enough:

The Java Kernel and Quickstarter  features in the JDK 6u10  release do improve download time and (cold) startup time, at least for Windows users. These techniques really just address the symptoms of long-term interconnected growth, however, rather than the underlying cause.

The modular JDK The most promising way to improve the key metrics of download time, startup time, and memory footprint is to attack the root problem head-on: Divide the JDK into a set of well-specified and separate, yet interdependent, modules.

He continues on about how this modularization would benefit the platform:

The process of restructuring the JDK into modules would force all of the unexpected interconnections out into the open where they can be analyzed and, in many cases, either hidden or eliminated. This would, in turn, reduce the total number of classes loaded and thereby improve both startup time and memory footprint.

If we had a modular JDK then at download time we could deliver just those modules required to start a particular application, rather than the entire JRE. The Java Kernel is a first step toward this kind of solution; a further advantage of having well-specified modules is that the download stream could be customized, in advance, to the particular needs of the application at hand.

Weijun comments on the original post, that the monolithic nature of the JDK is the result of Java not having a proper way of managing dependencies:

The JDK is big because Java never specified any industrial way of managing software dependencies.

Thus the only way to deploy reliably the Java stack was to bundle it in a huge monolithic monster.

Incidently, this does not work for third-parties, only for SUN and the JDK. The worst consequence of this lack of dependency management is not the bloated JDK but all the unmanageable apps which have been produced over time, with hardcoded classpath strings and massive forking (because if you can't manage deps and update them independently you may as well fork the private copy of the jars you're forced to bundle with your apps).

You don't have to look much farther to understand why Java only ever strived in J2EE servers (that provided a bit of the management lacking in the base Java platform).

GeekyCoder argues that a modular JDK is probably not a top priority for most developers:

While it may be "cool", I doubt that this is a top priority for most Java developers.

I have this bad feeling that you might be swayed by a handful of positive responses to your blog, without any idea of whether they're representative of the Java developer community as a whole.

Even just fixing the bugs that have the most votes would be a better strategy than just working on what's "cool".

I suppose "listening to your customers" is just one of those old-fashioned, closed-source ideas that has been thrown overboard. But look at the bright side...you now have two random developers who say they're willing to help. Good luck with that.

Similarly Michael B seems to think that enterprise users don’t care about a modular JDK:

A modular JDK (or rather JRE) is completely irrelevant to enterprise users. I think enterprise users prefer the "blob" as it is now, because modules mean dependencies and that smells like "DLL hell". The blob is easy to distribute and patch, that's what counts. Also, Java has good upward compatibility: Not only "write once, run everywhere", but also "write once, run forever", which means great return on investment (ROI). This is one of the reasons people prefer Java over .NET. MS strategy has always been: "Here's the new version of insert-favorite-hype-here, please retrain and port all your apps." MS technologies are way too short lived. The Java platform is already modular: The modules are third-party libraries that my app needs. I like the way Sun only makes libraries part of the platform when they have become mature enough. Robustnest and reliability are key to Java's success. So please go back now and fix those remaining bugs. I really liked that aspect of the 6u10 release!

You can find more information on the Java Platform or specifically on the Java SE right here on InfoQ.