Java SE: “Is That for Here or to Go?”

This is not an announcement of a new feature or a future project. We implemented a component deployment model, also known as JRE modularity, for the core of J2SE 5.0 and Java SE 6 back in 2007.

The goal was to let Java programmers bundle a light version of the Java Runtime with their applications leaving the unused components out so as to reduce the size of the installation package. Easier said than done, but we?ve got it made without breaking Java compatibility and called the technology Java Runtime Slim-Down.


It has been proved effective for many Java applications. For GUI applications, in particular, the size of a complete installation package with bundled Java Runtime starts from 5MB. Consider the following sample applications:

ApplicationGUI toolkitDownloadDescription
JavaCCnone3.9 MBThe most popular parser generator for use with Java

SWT4.6 MBSample program taken from Eclipse SDK, illustrates common Standard Widget Toolkit (SWT) controls

Swing9.0 MBPeer-to-peer tool to synchronize files between PCs in home-network, intranet
or over the internet

Swing8.7 MBPopular cross platform text editor

Click a link in the “Download” column to download the installation package.

Note also that:

  • these applications are wrapped in a GUI installer
  • the installed applications need not the JRE to run and do not download any components from the Internet (so they won?t disturb your firewall)

If you are in doubt, try it yourself. This flash demo will help you get started.

There are good reasons for end users to love ?all-inclusive? installation packages at reduced footprint rates, and it?s where a lightweight Java Runtime is of much help. The big question was how to make the technology usable and reliable? After all, we did not want to create a thing that does not work just because the programmer removed some components too aggressively.

We conducted some R&D and figured out that such a technology should come with tools that help the user not shoot himself in the foot and rules which, just in case, provide the fastest recovery. The final solution included a dependency analyzer and a ?safety net?.


The analyzer takes the application?s classes, infers what Java SE components are likely in use and advises to the user.

Fig 1. Unused Java SE components are marked green

Under the covers, it?s not simply checking import dependencies as that would work poorly in terms of precision. A more sophisticated analysis has been employed to reveal what Java SE components are used by the application.


Does it guarantee that any deployed application will never miss the removed components? I would not lay money on it. After all, a programmer could detach some components by mistake or an application may load a plug-in that uses the Java SE API more extensively than the application itself.

Here the following rule comes into play. All removed components are put into a detached package and the developer has to place it on a Web server at the URL s/he assigned when creating the installation. The Web server is considered a “safety net”: if the deployed application attempts to use any of the removed components, the Java Runtime will pull the package down from the server and load the requested Java classes.

Fig 2. Deployment

However, it is unlikely that a download of a detached package will occur in practice, provided the developer listened to the word of wisdom from the analyzer. For example, these sample applications have been downloaded over a thousand of times since we published them in May 2007, but there was not a single download of a detached package so far.


One man said that Java is a big heavyweight ball and chain. Good news: the ball is now optional! You may detach it and use module Chain only.


Learn more about Java Runtime Slim-Down

Watch a flash demo

Download Excelsior JET Evaluation Package

Categories: Excelsior JET, Java

Comments are closed.