Is JavaBE justified?

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

Class Granularity

% of rt.jar classes (size)


% of rt.jar classes (size)

6.0 b90

Extrapolated rt.jar size

Extrapolated download size

java -version

2.03 %

1.92 %

684 kB

5 MB


3.04 %

2.83 %

1 008 kB

5.1 MB

SwingSet2 (basic usage, simply clicking on each menubar item)

18.72 %

16.61 %

5 980 kB

5.6 MB

NetBeans 6.0 M1 (startup + compile/run HelloWorld + shutdown)

23.72 %

20.93 %

7 534 kB

5.8 MB

Yahoo! SiteBuilder (pretty basic usage)

25.76 %

22.20 %

9 180 kB

6.0 MB

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:

Package granularity

% of total rt.jar packages (size)


% of total rt.jar packages (size)

6.0 b90

Extrapolated rt.jar size

Extrapolated download size

java -version

9.80 %

9.75 %

3 474 kB

5.3 MB


11.85 %

11.02 %

3 927 kB

5.4 MB

SwingSet2 (basic usage, simply clicking on each menubar item)

38.33 %

36.43 %

12 968 kB

6.4 MB

NetBeans 6.0 M1 (startup + compile/run HelloWorld + shutdown)

44.16 %

40.94 %

14 592 kB

6.6 MB

Yahoo! SiteBuilder (pretty basic usage)

46.85 %

43.32 %

16 700 kB

6.8 MB

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

(authored and posted using StarOffice 8 soffice)

Author: alexismp

Google Developer Relations in Paris.

7 thoughts on “Is JavaBE justified?”

  1. Dear Alexis,
    I am one of your readers (human readers) and this post seems to crash Liferea – my RSS reader.
    Netbeans does not validate the feed:
    XML validation started.
    Checking file:/home/luci/alexismp.xml…
    cvc-elt.1: Cannot find the declaration of element ‘rss’. [4]
    XML validation finished.
    Is this related to “Star Office 8”, perhaps? Because until now nothing was wrong with your feed…

  2. says the feed is valid. You should probably report the issue to the Liferea guys (an invalid feed should really not crash an RSS reader anyway ;-)
    Sorry about that…

  3. Could you explain how you came up with the extrapolated download size? It doesn’t seem to be a compressed rt.jar ratio or a ratio to rt.jar vs the overall download.

  4. Hello Scott,
    The reasoning is this: rt.jar is responsible for about 4MB of a total of 9MB (45%), so I’m using the % found in column #1 or #2 (don’t remember which one I used) and apply it to 4MB and add up to the remaining 5MB. Let me know if that makes sense.

  5. You aren’t taking into account potential reductions in the number of DLLs included. For example I have unicows.dll on my XP system, but this should only be needed on Windows 9X systems. Then there are the like of keytool.exe, servertool.exe, that most people will never use. OK, none of these is large individually, but they do add up.

Comments are closed.