September 8th, 2006

Java Browser Edition: New name, wrong direction

Posted by Ed Burnette @ 6:20 am

Categories: Community, Eclipse, General, Java, Programming, Sun, Web Browsers

Tags:

Ethan Nicholas was recently hired by Sun to work on his dream of a Java Browser Edition. Except they’re calling it the Java Kernel now, and if initial experiments are any indication, the team will be straying quite a bit from the needs of the typical browser user. Ethan writes:

The first thing I have to do is establish that this project is feasible. So I figured I would start out by creating a simple, stripped-down JRE installer that contained only the functionality necessary to run System.out.println("Hello world!"), to get an estimate of the size reduction we could expect… 

I wrote a simple program which would iterate through all of the files in the JRE. It would remove a file and then attempt to run the Hello World program using this stripped-down JRE. If the test succeeded, the file was evidently unnecessary. If the test failed, the file was deemed necessary and restored.

In this way Ethan was able to get a minimal JRE that was 2.6MB in size.What we need is a competitor to Flash You might be thinking that sounds great, because it would compress down even further with a good compression algorithm like pack200. But as one reader pointed out, that’s still pretty large. A FORTH interpreter for example can be had for 8K or less. I remember writing one with my roomate (hi Mike!) long ago in Z80 assembler, so I think that’s a conservative estimate. Ethan responded:

I actually grew up programming Forth, so I definitely hear you. However, I don’t agree that the size of the VM represents a severe architectural problem. Even an extremely stripped-down Java VM is going to contain an optimizing compiler, a sophisticated generational garbage collector, a dataflow analyzer for verifying classes, cryptography functions for verifying signatures, and on and on.

Therein lies the problem with their current approach. What we need is a competitor to Flash. This means:

• It needs to be the same size as Flash or less (200K-1M max).
• It should install just as quickly and easily as Flash.
• It should update itself like Flash.
• It should support streaming like Flash (including streaming video and audio).
• It should be bundled with browsers (yes, even MS IE) like Flash.

In short, it needs to almost *be* Flash, except with the Java language (or some subset thereof) instead of ActionScript/SWF.

The team’s grander ideas about using the JSR 277 module system, downloading functionality on demand, and full Java SE compliance sound good on paper, but does it really help solve simple user problems? No. Well, you might say, why does a user care if this thing running in their browser is written in ActionScript vs. being written in Java? They don’t, but they will benefit from the increased productivity that comes from developers being able to use a common language and development environment for all platforms, containers, and targets. Increased productivity translates into decreased time to market, improved quality, and more innovative applications.

Forget about jar files and conventional class loaders. Verify ahead of time. Simplify everything. Heck, it doesn’t even need a JIT. It doesn’t need to be Java SE compliant or run old applets. It can be something completely new.

Some wonderfully popular applications have been written with J2ME, and GWT has shown that subsets are beautiful too. Let’s have a JSR not for a Java Kernel, but for a real Java Browser Edition. Let’s have "browselets" instead of applets and midlets. Consider a subset of SWT (maybe eSWT?) for the UI so it will fit seamlessly with native browser widgets. Break the mold, discard conventional thinking, and embrace the idea of Java everywhere with editions customized for the needs of users on each platform.