Because the resource requirements for Java
Standard Edition are by no means insignificant, developers
interested in utilizing Java on smaller platforms have
traditionally opted for one of the Java
Micro Edition configurations. It should
therefore come as no surprise that some of the Standard Edition
functionality has to be sacrificed in these constrained Java ME
environments. However, as the trend towards more capable
devices continues, it becomes reasonable to once again consider
the advantages of utilizing Java SE. Unfortunately, with a
static footprint that could easily exceed 100MB, Java SE may still
be too large to swallow for a lot of applications.
It is duly noted that the criticism leveled at Sun for exacting
too much control over the Java platform has been widespread.
Like it or not though, one benefit of Sun's initial stewardship
has been that Java SE has remained a standard platform, and
threats to splinter it have thus far been reasonably
thwarted. Accordingly, in order to avoid incompatibilities,
there are restrictions spelled out in the Java
SE Licensing Agreement which prohibit modification of the
Java SE binary distribution.
That being said, there are a list of optional files,
specified by the Java Runtime Environment's README file
which can be removed, without ramification, to lessen the
footprint. They include:
In addition, further space optimization can be achieved by compressing the class library files contained in the rt.jar file. By default, Java SE ships this jar file uncompressed. The tradeoff here is space vs. performance, i.e. the classloader must expend cycles to uncompress the Java classes as they are being loaded.
An Example
So let's download a sample JRE from java.sun.com and see how it's footprint can be minimized. For this example, we'll use Java SE 1.5.0 Update 13 for Linux x86.
After installation, the JRE is approximately 88MB
jimc@jalopy:/tmp> du -sk ./jre1.5.0_13/
88185 ./jre1.5.0_13/
Here's what it looks like after removal of the optional files
jimc@jalopy:/tmp> cd jre1.5.0_13/
jimc@jalopy:/tmp/jre1.5.0_13> /bin/rm -rf lib/charsets.jar lib/ext/sunjce_provider.jar \\
lib/ext/localedata.jar lib/ext/ldapsec.jar lib/ext/dnsns.jar bin/rmid \\
bin/rmiregistry bin/tnameserv bin/keytool bin/kinit bin/klist bin/ktab \\
bin/policytool bin/orbd bin/servertool bin/javaws, lib/javaws/ and lib/javaws.jar
jimc@jalopy:/tmp/jre1.5.0_13> cd ..
jimc@jalopy:/tmp> du -sk ./jre1.5.0_13/
77227 ./jre1.5.0_13/
And after rt.jar has been compressed
jimc@jalopy:/tmp> mkdir rtjar
jimc@jalopy:/tmp> cd rtjar/
jimc@jalopy:/tmp/rtjar> jar -xf /tmp/jre1.5.0_13/lib/rt.jar
jimc@jalopy:/tmp/rtjar> zip -q -r /tmp/rt .
jimc@jalopy:/tmp/rtjar> mv /tmp/rt.zip /tmp/jre1.5.0_13/lib/rt.jar
jimc@jalopy:/tmp/rtjar> du -sk /tmp/jre1.5.0_13/
59358 /tmp/jre1.5.0_13/
Conclusion
In many cases, you can lop off about a third of the Java Runtime
Environment footprint with no ill effects. In a future post,
we'll discuss how Sun has further reduced Java SE significantly,
not only from the point of view of static footprint, but also from
a RAM usage perspective too. For a preview you can check out
Sun's Java
SE Embedded technology.
Index