Thoughts on "The Modular JRE" and Open Sourcing Java
David Herron posted a clarification of "what it means to be Java" on his blog, and the examples that he used got me thinking...
David made it clear that anyone can add whatever they like to their version of the JRE (Java Runtime Environment) and still call it Java... but if they leave anything out then it is most certainly not Java. The example he sited was the hypothetical incusion of SWT (the windowing toolkit used by Eclipse) in a version of the JRE. This version could still label itself as Java as long as AWT and Swing (the windowing toolkits in the Java specifications) are not excluded.
This makes sense to me... but I'm hoping that the folks who are opening Java also take another look at the basic definition of what must be in the JRE. Let me explain my concern...
Many Java applications (maybe even most) have no desktop-based user interface at all (they are browser-based web applications)... and if the adoption of Web Services and SOA continue we'll see more and more "headless" Java-implemented Services (Services that have no user interface at all). In a world where it is quite legitimate to have a large percentage of Java applications with zero need for any windowing toolkit, why carry around those toolkits in the JRE?
I know that code that isn't used doesn't really "cost" much, but let's assume that you are really into Grid computing, and you have thousands of nodes in your cluster... and each node has a JRE with unused windowing toolkits on it. Seems wasteful.
Windowing toolkits in the base JRE are fairly easy to throw stones at, but there are many other components that really should be optional. For an example, just take a look at the recent "discussions" on whether or not JavaDB should be included in the Java Developer Kit (I shudder to think of the threads that would be spawned if JavaDB is ever packed into the JRE).
My impression is that there is a large consensus that the JRE should be more modular, broken into logical chunks that are installed based on need. A modular JRE does pose some rather interesting technical challenges (to get the code that you need when you need it), but I had overlooked the challenge posed by the current definition of Java itself.
If I'm reading David right... a modular JRE wouldn't quite meet the current definition for "Java"... it's all or none. If I never install the "windowing-toolkit" chunk on my application servers, then they aren't really "Java" application servers.
Just something to think about...
(cross-posted at Thoughtful Programmer)