Formerly lead engineer of Yahoo's publishing tools team, and original author of the Yahoo SiteBuilder Swing app, Ethan Nicholas lamented back in April:

I face a frustrating problem: Java is the most powerful browser-based technology available, easily besting competitors like Ajax and Flex, and yet I can't use it.

He proposed a Java Browser Edition, with a small initial kernel under a few megabytes in size, and with the ability to download APIs on an as-needed basis.

Since July, Nicholas went to work for Sun. As part of the Java deployment team, part of his job is to turn that vision into a reality. His most recent blog post, "Java Browser Edition": New name, first steps, recounts how he was able to create a special version of the JRE capable of executing "Hello, world" in 2.6MB, and another JRE version with AWT support in just 3.5MB.

Nicholas' work is part of an effort at a Java Kernel, slated for release in JDK 7. Artima asked Nicholas about how this work would help Java developers:

Before joining Sun, I worked for Yahoo. The issue of the JRE's download size was a constant shadow over all our attempts to use Java on the client side. Advanced applets? The JRE is too big to justify them. A big client-side application like Yahoo! SiteBuilder? This barely got management approval, and I assure you that the JRE download size was an enormous concern throughout. The fact that I could join Sun and potentially help fix this issue once and for all was very exciting to me.

This has an impact in every situation where a JRE might need to be downloaded. That means applets, Java Web Start programs, and even traditional client-side applications downloaded via the Web. By significantly reducing the download size, we make Java a more attractive option in many of these cases.

While rich-client Java sports capabilities beyond what Ajax or Flex offer, applets have been one of Java's sore spots. Nicholas notes that:

There are a few major issues preventing widespread use of applets. First, it's difficult or impossible to ensure that you have the right version of the JRE present. You can't simply say "This applet needs Java 1.5" the way you can with a Web Start application., Second, for users without the correct JRE, the download is very large and takes too long to install. Third, applets take too long to start up. [And], fourth, there are reliability problems—applets sometimes inexplicably fail to start, LiveConnect may not work for some unknown reason, and so forth.

It's hard to say how much impact any one of those problems has individually, because if we fixed just one there are still other significant issues getting in the way. I think that for applets to succeed, we need to fix all of these issues, and we are going to do our best to do so for Java 7. Java Kernel is aimed squarely at [reducing JRE download size], but there will be other people and other projects looking at the rest of them.

While JRE download size is a key impediment to widespread applet deployments, so are the quirky, and often buggy, applet implementations of browsers. However, Nicholas notes that,

The situation has improved tremendously from the dark days of Java 1.0.2 and the Microsoft VM. The Java Plug-In included with Java 6 actually starts very quickly on a modern computer, and via things like the Common DOM API you can do a lot of neat tricks. The goal with applets in Java 7 is to fix the remaining issues and make applets a viable choice again.

Nicholas pointed out that a dynamically extensible, small JRE kernel will be an important tool to help manage the inevitable growth of the Java platform:

Sun has been fighting for years to keep the JRE down to a reasonable size. Because every feature added to the core platform increases the size of the download, that has meant having to very carefully weigh the benefits of adding the feature versus the cost of the additional download size, and has led to various Java APIs not being part of the core JRE. With the combination of the Java Kernel feature and the Java Modules being developed in JSR 277, this problem might go away.

Here's how it will work. Suppose your program requires, say, the Java Media Framework. In Java 6, as it isn't part of the core APIs ... you will have to deal with distributing and installing [it] on your own...

In Java 7, with the Java Kernel, we could treat the Java Media Framework as "yet another downloadable module." There will be mechanisms to specify that you need this functionality if you want to make sure it is downloaded prior to your program starting up, or you can simply wait until you need the functionality, and then attempt to access it as if it were already present. In either case, the Java Media Framework will be automatically downloaded and installed, and you don't have to do anything more complex than attempt to access the APIs.

It gets better, of course. We can potentially do this for every Java API which isn't currently in the core JRE so that all of them are available on demand to all programs with no special effort. You just access the APIs as if they were already installed. And after the Java Kernel itself is installed, it will automatically begin downloading additional functionality in the background while your computer is idle...

Now of course the situation I just described—being able to access all Java APIs as if they were part of the core JRE—may not actually come to pass, as there will be a lot of politics involved in trying to get it to happen. Regardless, I think Java Kernel is a very exciting feature and will really make a difference to developers.

What do you think of the approach Nicholas described to managing the growth of the JRE? And what would it take for you to consider applets once again a viable deployment alternative?