John Reynolds's Blog

Community: Embedded Java Archives

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

Off topic blog on Distracted Drivers...

If you have any thoughts on how Java might be used to help solve the "distracted driver" problem, please leave your comments here.

Thanks,

-JohnR

Big dreams on the longest night of the year...

The past year has seen a lot of progress in enterprise computing. At the beginning of this year I was writing an "elevator speech" on Service Oriented Architecture to introduce the concepts to my IT colleagues:

"This talk will be far more evangelical than technical, and I hope that it will de-mystify SOA for some. I'm sure many of you will say "Duh!" when you read some of the points, but you'd be surprised how many folks just don't get it (yet). "

The other big story of 2005 has to be AJAX (Adaptive Javascript and XML). I first blogged about AJAX in March after witnessing an amazing demo by Dion and Ben. I was wowed by the possibilities, but haunted by:

"memories of pre-custom tag JSP pages... a little puddle of HTML markup embedded in an ocean of Java code (only this time it's JavaScript)"

AJAX and Service Oriented Architectures are fond remembrances of the recent past... What about dreams for the future?

David Gelernter said the following during an interview for the Sun Developer Network:

"Huge numbers of "non-technical" people rely on computers not because they want to but because they have to. The great author and culture-critic George Orwell noted 60-odd years ago (and I noted in Mirror Worlds) that some people like playing with machines; some people don't. People who don't are just barely hanging on today. They need something far simpler, far more powerful than they've got today"

I think that SOA and AJAX are catalysts for the "far simpler future" that most people need. At first glance, you may not see the linkage, but take another look.

Web Services are what makes AJAX sexy. AJAX is what makes Web Services accessible to the masses.

As the SOA mindset takes hold, we should see an explosion of web services. As the AJAX toolsets mature, it should become incredibly simple for "power users" to craft tailored solutions from the new bounty of web services. Throw in improvements in service orchestration and choreography (BPEL for People anyone?), and I think we'll see a new generation of Renaissance Artist/Programmers.

In a recent interview, Bill Buxton offered the following scenario:

"The interesting thing is if you can throw a cell phone on a passenger seat, the phone rings, and the phone says to the stereo, "There's a call coming in. Can you turn the music down and can I borrow the speakers? And by the way, can I use the microphone embedded in the steering column?" Now you can just talk hands-free."

In Bill's example, the stereo provides an "audio output" service, the the microphone provide a "voice input" service, and the phone provides several communication and choreography services. The key is to help the "Renaissance power user" discover these services and then to help wire the services together on-the-fly. The pieces of the puzzle exist, the challenge is to make it easier to put them together.

The languages, tools, and devices that deliver this kind of power to the new Renaissance men and women are what I plan to dream of tonight...

Pleasant dreams indeed ;-)

This work is licensed under a Creative Commons License.