The Problem

The Java programming language has often been thought of as a tool for writing platform independent programs. Java's "Write once, run anywhere" approach is based on the idea that a compiler for a Java program generates generic byte code that can then be interpreted and run by a Java Virtual Machine (JVM) on any platform. The problem is that today's Java programmers must constantly be concerned with which version of the JVM their application requires, and whether or not this version will be present on the end-user's machine. The following is a list of the common solutions for this problem and how they are costly:

1. The application requires that the end user fetches and installs the JVM - Today's users have come to expect a simpler installation procedure. Many do not know what a JVM is and cannot be relied upon to successfully install one.
2. The JVM is packaged with the application - JVM's are very large (~ 20 MB) and can cause installers to be unnecessarily large. Naively installing a JVM can also lead to the same JVM being installed on a system more than once. Furthermore, successive updates to the software can involve re-installing a new JVM. This can perpetuate the problem indefinitely.
3. Custom Solutions - Coming up with a custom JVM update and management facility can cost development time, and custom solutions are often inflexible and hard to maintain.

The Solution

JEM (Java Environment Manager) is a lightweight native application that frees both the user and developer from the concerns of JVM management. From the developer's perspective, you simply place the JEM application (~280 KB) in with the Java application along with a configuration file specifying the application's launch environment. In the configuration file, the developer specifies the runtime environment and launch parameters along with the versions of the JVM required for the application to run properly. From the users perspective, they launch the application by executing the JEM executable (which, of course, is disguised as the target application). JEM then takes care of JRE detection and the launching of the application. If a proper JVM is detected on the system, it is used to launch the application. Otherwise the JVM is automatically downloaded and installed for the user before the application is launched. This solves the problem of JVM management for both parties:

1. The user never has any knowledge of JVM management. From their perspective, the Java Application runs just like any other.
2. The developer no longer has any worries about JVM management or runtime configuration. This frees them to concentrate on the features and performance of the application.
3. The developer has complete control over the runtime environment of the application. They can be assured that their application is being run with the correct version of the JVM at any time.
4. If a future version of the application requires a new version of the JVM, the developer only needs to specify this in JEM configuration file. JEM will then handle the download and installation of this new JVM when the application is run.