Deployment: Understand JRE download size
I talked to many developers recently about the Windows JRE download size issue. The conversation often went like this:
Stanley: What do you see as the major obstacle of your deployment?
Developer: JRE download size is definitely a problem, especially on Windows.
Developer: The JRE is 25MB, and it is beyond what most consumers are willing to download.
Stanley: Actually, the full download size of JRE 5.0 is ~15MB, and you could get a minimal download of ~7.2MB if you use the online installer.
Developer: Really? I didn't know that. I thought the JRE was '25MB' because that's what I've always heard.
Obviously, there are some misunderstanding among Java developers about the JRE download size. It is time to do a reality check!If you go to the J2SE 5.0 Update 3 download page and download the JRE, you will see these numbers:
Apparently, the offline installation is ~15MB, and the online installation is only 221KB?! Note: most JRE installers for Linux/Solaris are also ~15MB.
What exactly are the online and offline installation?
The online installer was introduced in Mantis (J2SE 1.4.2) in response to the critical install issues at that time:
1. The JRE was big for most end users to download, and average users only needed the core features.
2. If you developed in Java long enough, you probably still remember there were separate English and I18N bundles. If you installed the wrong bundle on the machine, the only way to fix it was to uninstall the wrong bundle and reinstall the right bundle. Obviously, there were lots of frustration over this issue, and it forced most developers to always bundle the (larger) I18N JRE with their applications.
3. There were a few goodies developers wanted but they were only bundled with the JDK, e.g. sound bank, color profiles, additional fonts, etc. Their unavailability generally discouraged their usage.
4. Lack of incremental update between JRE releases.
To address these issues, William Harnois, Kumar Srinivasan, and I decided to implement the install-on-demand feature in the Windows JRE installer. Our approach was to separate the Windows JRE into three features:
1. Core: Western JRE, with Java Plug-in and Java Web Start. This feature is always installed.
2. Other: Other languages and locales. It is installed by default on platforms that support non-Western locales
3. Extras: Sound bank, Color profile pycc.pf, Lucida fonts beyond Lucida Sans Regular.
Architecture of the Windows JRE online installer:
Architecture of the Windows JRE offline installer:
With install-on-demand, the online installer is simply a bootstrap that understands how to pull down the rest of the features from the web, while the offline installer basically packages everything into a single bundle.
Using the online installer, end users only need to download the critical features of the JRE to run their Java applications. One thing to notice is that the full set of J2SE APIs are available if you download only the core feature, so there is no platform fragmentation issue. The next obvious question is: what is the minimal download using the online installer?
If you look at the online installer architecture carefully, the only components that users must download are: bootstrap, MSI database, and the core feature, and the total size of these components is what we called the minimal download size. In JRE 5.0, the minimal download size is ~7.2MB. If you install the Other and Extras features, it is ~10MB.
Wait a minute! If the total download size for all features is only 10MB, how come the size of the offline installer is ~15MB? This is because some Windows systems do not have the Windows installer engine installed, but the installer engine is required for our JRE installation, so the offline installer must bundle the engine together for distribution, and it adds additional overhead! The online installer does not have this issue because it could download the Windows installer engine from the web if necessary.
The good news is: the online installer could give you ~7.2MB minimal download, and it is much smaller than many developers thought!
There is more! If you install a JRE update release (i.e. W.X.Y_Z) using an online installer and you already have an installed JRE in the same family (i.e. W.X.Y or other W.X.Y_Z) on the machine, the download could be further reduced through incremental update with base image patching!
What is incremental update?
In traditional patching, a patch is often generated between the last up-to-date version and the new version of the software image.
In this approach, you could run into all sorts of versioning slew issues. For example, a patch can only be applied if the installed image matches the version that the patch targets. Synching up the mismatch version of the installed image could be very painful, and users may be forced to install dozens of patches in order to bring their local images up to date. Patch installation also yields a different user experience than installing your regular application, and patch management could be very complicated. Fortunately, most of these issues could be avoided in base image patching.
In base image patching, a particular version of the software is defined as the baseline, and its software image is defined as the base image. Patches for subsequent releases of the software are always generated with respect to the base image:
In this approach, a patch can be applied only if the base image is already installed. What is really interesting is that the patch size generated through base image patching is very comparable to the one from traditional patching when we applied this scheme to the JRE.
Since Mantis, we have supported incremental update by leveraging base image patching under the cover of the JRE installer. When a JRE installer is built, the installer actually contains a base image and a patch. For example,
- 1.4.2 -> 1.4.2 base image + no-op patch
- 1.4.2_01 -> 1.4.2 base image + 1.4.2_01 patch
- 1.4.2_02 -> 1.4.2 base image + 1.4.2_02 patch
- 1.4.2_0X -> 1.4.2 base image + 1.4.2_0X patch
- 5.0 -> 5.0 base image + no-op patch
- 5.0u1 -> 5.0 base image + 5.0u1 patch
- 5.0u2 -> 5.0 base image + 5.0u2 patch
- 5.0u3 -> 5.0 base image + 5.0u3 patch
- 5.0uX -> 5.0 base image + 5.0uX patch
When a JRE is installed, the installer will always attempt to store the base image in a repository on the machine first in case the base image is absent. If the base image is present, the installer will retrieve the base image and apply its patch to generate the appropiate version of the JRE image for your installation.
Why does it matter to you? If you always use the offline installer, it probably won't make any difference. However, if you use the online installer, the incremental update support could significantly reduce your minimal JRE download size even further. For example, if you already have a 5.0 family JRE installed on the machine, installing a new 5.0 family JRE will only download ~2MB (patch + installer overhead). As a result, the download is much smaller, and the installation is much faster!
Because of the benefits in download reduction, we actually used the online installer for java.com and Java Update in many download scenarios.
As a side note: Java Update is a software to deliver JRE update to end users regularly and automatically. Contrary to common belief, Java Update does NOT do any patching; it is actually the downloaded online installer that does the magic!
Consider bundling the JRE online installer.
If you need to bundle a JRE with your application, you may consider bundling the JRE online installer and take advantages of all the download reduction benefits I outlined above. The bootstrap is less than 250KB! Incremental update is only ~2MB! Even if you don't have a base image on the system, the minimal download is only ~7.2MB. There is a catch though Your users must be online during the JRE installation, and the success rate of the installation is subjected to the network and server condition.
Hopefully, you should now have a better understanding on the JRE download size issue. Of course, we will continue to think hard on how to reduce the download size even further. Tell us what you think!
Note 1: Some of you may wonder how I came up with download size number. The number was determined by simply adding up all the necessary files the online installer must download for the core feature. However, the online installer is hosted on the server side, so it is difficult for general developers to calculate the number themselves.
Note 2: The Windows JDK installer also follows similar architecture.