John Reynolds's Blog

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

Comments

• From my perspective,

  Especially for a server, even the full bloat is not very much to carry, and furthermore it is not loaded into memory if it is not being used. However I can understand David's (or more appropriately Sun's) point.I have 'headless' servers that remote fully configured interactive user interfaces to remote clients. In order to do this, they need the graphical libraries. Believe it or not, a Java Headless Enterprise Edition (the marketing guys would literally freak over that one) would actually break my servers.Essentially a contract of capability has been made, and people have designed code to rely on it. Backward compatibility is a harsh mistress; but what was that old saying about Hell hath no fury...

  Posted by: cajo on August 22, 2006 at 02:26 PM

• I'm not quite following you on this one cajo.It seems to me that it is the application that you are deploying on your Java Headless Enterprise Edition that requires the windowing toolkit libraries... and I don't quite understand why you wouldn't package those libraries with your application, rather than require them to be part of the application server itself.But then again, I'm sure you've thought this through.-JohnR

  Posted by: johnreynolds on August 22, 2006 at 02:59 PM

• The Java spec requires that AWT be available, but doesn't (as far as I know) specify how long it might take to load the classes involved. Thus it seems to me that download on first use would be permitted. It would be nice if there was an API that allowed you to find out if a given class was available locally or would be downloaded if used.
  In short though I think a moduler JRE is permissable provided that applications only see an extended class load duration when using an API not previously installed locally.

  Posted by: mthornton on August 23, 2006 at 06:08 AM

• Interesting thought mthornton,We'd have to account for the error case where the device was "disconnected" and unable to download the AWT libraries... Perhaps your proposed API should take that into consideration.-JohnR

  Posted by: johnreynolds on August 23, 2006 at 06:17 AM

• Of course the download may fail, but then so might the disk containing the local JRE! If a modular JRE was implemented there a number of things that ought to be done to make it friendly to both end users and developers.

  Posted by: mthornton on August 23, 2006 at 07:09 AM

• Hi John.

  It's certainly an interesting notion that a modularised JRE might not qualify for the 'Java' branding. My gut feeling is that providing all the necessary components are available (by whatever means) this shouldn't cause any problems. But I'm not a lawyer :)

  It is certainly a valid question to ask, and I suspect something which Sun need to clear up as part of the OS process.

  As for an API for checking the availability of packages, can I plug my recent ramblings on how issues like this might be solved? (Too late, just did! :)
  

  Posted by: javakiddy on August 23, 2006 at 07:37 AM

• You can actually remove a lot and still call it Java. gcj has next to nothing and calls itself Java with no repercussions for example...
  After all, the core libraries are NOT part of the language per se, so you can create something that fits nicely inside the JLS while removing most of them. Of course most Java applications will no longer work, but that doesn't seem to bother most people as long as their own still works as expected, and they'll of course make sure of that.

  Posted by: jwenting on August 23, 2006 at 09:26 AM

• Or just don't distribute "Java" and instead distribute an app with some sub-JRE bundled. For "native" apps, this could really slim down the download time, and this will be one of the side wins for open source Java.

  Posted by: tjpalmer on August 23, 2006 at 11:52 AM

• To supplement the point made by tjpalmer, this is already done today and most people end up with 5+ JVM's on the machine over time (I have 12 java.exe on my machine).

  Posted by: mrmorris on November 23, 2006 at 06:19 PM

This work is licensed under a Creative Commons License.