I've been following the Java BE (Browser Edition) debate and it seems that the main argument in favor is the download size, so I though I could try to actually come up with some numbers on the benefits of such an approach. Unlike John, I believe this would only make sense on the desktop client as the BE name suggests. Anyhow, the reasoning below applies with the same conclusions I think.

A JRE installer is about 9Mb these days (JRE 1.5.0_07 for Windows). Of those 9Mb, rt.jar is responsible for about 45% (37Mo on disk after Pack200 decompression). Some JRE downloads are more than 9Mb bringing to the user extended charsets, audio sound bank, fonts, etc which arguably could be useful for Desktop Java applications. First thing to note, is that even with the smallest rt.jar of all, the download size could go not below 5MB.

After measuring the size of each class in rt.jar, I ran several tests to see how many classes were actually loaded/needed by several applications and how much they weighted. I simply used -verbose:class (one of my favorite troubleshooting option) and analyzed the standard output to sum-up the total class size. Since I'm not looking at startup time, I also shut off the class sharing mechanism using -Xshare:off to precisely track everything loaded from rt.jar. Yes, using HotSpot's JMX instrumentation could have been more elegant. Let's call it exercise for the reader :-)

Windows's JRE 1.5.0_07, rt.jar is worth 12 574 classes (not all public) for a total of 35 642 678 bytes. For Mustang Java 6 b90, it's 15 843 classes for a total of 43 051 263 bytes (a 20% increase in the total size of classes, responsible for about a 700k increase of the installer).

That may look interesting, but something like Java BE would mean that the developer has to have a precise set of APIs which he can rely upon at runtime. These API have to be discrete packages and not a bunch of unrelated classes, so this is what is really looks like when you use one of the 724 rt.jar packages (both public and private ones) as the level of granularity:

With the same technique and a longer use of NetBeans (to develop the small app to come up with the above results), I went as high as 6.92 MB for the JRE download size (49% use of rt.jar).

For UI applications, on-demand downloading of class or JAR files doesn't seem reasonable. While bandwidth is not comparable, it reminds me of the applets times with no jar format. Somehow I'm confident Java Modules (JSR 277) will help here.

So, if Java BE's point was to make the download size smaller, hence making it easier to download/bundle/install, I don't believe that there's that much room for improvement and we're not really close to the 1MB download. At least not if Java BE is meant to be a subset of Java SE. Rather, Java ME's profiles (such as CDC JSR 209) could be good candidates.

Now of course, I've only dealt with rt.jar and not with various shared libraries' footprints (the other 55% of the JRE download size) and I still do think there's plenty of room for improving the Desktop Java experience. Ethan Nicholas (who started the whole JavaBE thread and who's now at Sun part of the Java deployment team) and others have a lot on their plate (and a bit of data too).