No More JRE Packaging? No Big Deal

DZone 's Guide to

No More JRE Packaging? No Big Deal

Don't worry about the JRE. Focus on the JDK.

· Java Zone ·
Free Resource

Historically, when opting to install Oracle's (and previously Sun's) implementation of the Java platform, users have been presented with two options:

  1. Download and install the Java Runtime Environment or JRE.
  2. Download and install the Java Development Kit or JDK.

Speaking from years of customer interactions, there is still a good deal of confusion surrounding these two terms. The predominant choice for desktop users is the JRE. It contains all of the necessary components required to execute Java programs including the Java Virtual Machine, the Java Class Libraries, and the (now) legacy client deployments technologies like the Java Plugin and Java Web Start. The JDK, on the other hand, encompasses everything in the JRE plus all of the framework and utilities required by Java developers. And it is a lot bigger. To give one such example, as of this article's publish date, the JRE for the most recent Oracle Java 8 update (Java SE 8 update 191) consumes 196 MB on a Windows 64 system, whereas the JDK version takes a whopping 366 MB disk space.

As has been announced some time ago, the Java Plugin's and Java Web Start's days are numbered. In fact, with the release of JDK 11, they are officially gone. Kaput. Never to return. And correspondingly, neither OpenJDK nor Oracle JDK 11 provide a JRE option for download either. Why did that happen?

To start, the JRE is a Sun/Oracle-only creation and not a real part of OpenJDK. In its quest to make the Oracle JDK and Open JDK as indistinguishable as possible, eliminating it makes some sense. With the removal of the aforementioned client deployment technologies, one could also argue the primary reason for the JRE's existence has gone away too. If a version of the JRE were to be produced for JDK 11, it would look a lot different than previous JREs. Finally, justifying the continuance of the JRE as a means to package a smaller footprint Java can be questioned with the introduction of Java modularization in JDK 9 and subsequent advances in JDK 11. Let's see why.

Starting with JDK 9, a lot of work has been put into making a more efficient binary platform. A simple examination will find the innards of new Java binary releases entirely different. Gone are the days of distributing the antiquated (and humongous) rt.jar file as a means of providing the wealth of Java class libraries. As a consequence, the footprint is reduced and can be made smaller with relative ease. For example, the most recent Oracle JDK 11.0.1 release has a disk footprint of 277MB, as opposed to the previously mentioned 366 MB for Java 8 update 191 JDK on the same hardware/OS. And if you want to create a perfectly legit runtime that is smaller than the originally packaged Java 8 JREs, just do these two simple things to a JDK 11 distribution.

  1. Delete the contents of the jmods/ directory. This eliminates about 74 MB.
  2. Delete the lib/src.zip to save an additional 45+ MB.

Performing these tasks erases some of the traditional developer functionality that comes with the JDK, in effect, making it look closer, but not identical to, an old school JRE. And it does not affect the resulting runtime's ability to execute Java programs. This modified JDK 11 runtime consumes about 157 MB, nearly 40 MB smaller than typical Java 8 JREs.

Final Thoughts

The astute may have noticed that Oracle also produces a Server JRE. What about that? The Server JRE term is a bit misleading. It is not a JRE but rather a JDK that happens to include a specific Java Virtual Machine called the Server VM (as opposed to the client VM). Chalk this up to nothing more than an unfortunate and questionable naming decision. Lastly, the ability to make even smaller, customized runtime Java images can be accomplished via the jlink tool. Further edification on that topic is left to the reader.

java 11 ,java ,opinion ,jdk ,jvm ,jre ,packaging

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}