Insights and updates on Java SE and OpenJDK from the Java Platform Group Product Management Team

  • February 27, 2014

Managing multiple Java versions

Guest Author

The Java Platform provides various options for System Administrators to manage updates on client systems and maintain compatibility with specific applications

This post is intended to guide System Administrators whose clients make use of Rich Internet Applications (Applet & Web Start). Most of this does not apply to System Administrators of server-side applications or locally installed applications using the JRE.

The primary strategies for controlling RIA compatibility are:

  • Identify known RIAs.
  • Install Java versions through patch-in-place or static installation mode.
  • Deploy the latest version of Java.
  • Delegate certain RIAs to use specific Java versions.

Quick Example: A company has a back-office application for managing contractor timesheets. The application is known to require Java 6. The System Administrator should install the latest Java 7. After installation, the system administrator should statically-install the desired Java 6. The System Administrator should then create a Deployment Rule Set to indicate that a specific RIA requires Java 6.

Identify known RIAs

In order to whitelist RIAs and delegate certain RIAs to specific Java versions, the first step is to identify where those applications are. The two primary ways of doing this:

  • Location, the https:// or http:// or other protocol URL where the RIA is hosted and accessed by users. You will be able to wildcard these later. This is easiest when you control or host the destination, such as inside a company.
  • Code signing hash, an identifier of a vendor based on their public signing certificate. This can be easier when you have a number of RIAs from a particular vendor.

The way of identifying RIAs will vary between organizations. One important consideration is to provide a way that users can contact you with adjustments, for example reporting an RIA that you may have missed.

Install Java versions through patch-in-place or static installation mode

The JRE installation mechanism provides two types of installation: Patch-in-Place and Static Installation. The default mechanism is Patch-in-Place because it leaves a smaller footprint. It also intentionally does not leave older versions behind. Static Installation intentionally leaves behind the older version so that it can be used to execute specific RIAs.

Patch-In-Place Static Installation
Default: Yes No
Installation area: C:\Program Files\Java\jre7
Newer versions update this directory.
C:\Program Files\Java\jre1.7.0_##
Newer versions get their own directory.
Leaves older versions: No Yes
RIA Deployment Flow defaults to: The only version installed. The highest version installed.
Used for: Most cases Large environments where known applications require a specific older version of Java.

System Administrators can specify their preference when automating installation of the JRE.

In general, Patch-In-Place is the best default and you should use static installations only on systems known to require a specific version.

Deploy the latest version of Java

Users should always run the latest secure baseline. The latest version of Java always provides the best security defense and enterprise management features. For example, users needing to execute an RIA with Java 6 (end of public updates was in February 2013) should use the latest Java 7 version and let it delegate to Java 6 for the specific RIA.

Java installations contain two features to stay up to date: a security baseline and an expiration date. The security baseline represents the latest Critical Patch Update, whose schedule is published a year in advance. A separate "expiration date" is built-in for clients that cannot dynamically check this security baseline. The "expiration date" set at about a month after the scheduled critical patch and is documented at Java.com for the latest version as well as the Oracle Technology Network release notes for specific versions. Once a JRE detects that it is below the security baseline, it changes its behavior as described in the RIA Deployment Flow Guide.

The Deployment Flow process (including expiration date) can be controlled by delegating certain RIAs to use specific Java versions.

Delegate certain RIAs to use specific Java versions

The majority RIAs are compatible with the latest Java release within major versions. For example, an RIA that runs with JDK 1.7.0_01 is expected to be binary compatible with higher updates like JDK 1.7.0_51.

For specific applications where compatibility issues have been verified, System Administrators can use Deployment Rule Sets as a way of associating a specific RIA with a statically-installed Java version. When specifying a version for your DRS, it is easiest to go in order of: SECURE (no version), then SECURE-1.X (major version only), and only use specific versions like 1.7.0_51 for a verified compatibility issue. Because rules are specified explicitly by a system administrator, their results are applied before other checks that would affect program execution.

If you create any rules that DENY an RIA from running, it is a good idea to provide a way for users to contact you.

Deployment Rule Sets must be cryptographically signed. Commercial code-signing certificates are recommended but if you prefer to self-sign your Deployment Rule Set, you must distribute your public key to clients before they can recognize your signature.

The Deployment Rule Set files are installed to an area outside the Java installation directory and will remain active as clients update their Java installations.

For additional information, please see the complete Deployment Rule Set documentation.

Deployment Rule Set Version request

When specifying the version in a Deployment Rule Set, it is best to choose a version equal to or higher than the one requested by the launching JNLP file. If you specify a Java version below what the application says it needs then it is unlikely to run correctly.  Inside the JNLP file, there is a section that will look like <j2se version="1.X+" />

If the JNLP requests a version and you specify something below, then the application will be blocked.

If the JNLP requests a version and you specify something at or above, then it will run with what you have specified.

Specifying a version in your Deployment Rule Set that looks like SECURE or SECURE-1.X is often the simplest choice.

Join the discussion

Comments ( 2 )
  • Bujjanna Monday, March 3, 2014

    caller-allowable-codebase value changes for each of my customers as their domains and machine names differ, how do i create a different jar for each customer? there is no way for me to know what their machine name?

    only option I am left with is to use '*' but the whole purpose of the attribute is lost if i use a start. How is it handled? please help

  • costlow Monday, March 3, 2014

    For others reading these comments, the role of Caller-Allowable-Codebase is unrelated to this blog post.

    You're welcome to create a different JAR per customer, but I probably wouldn't go to that length. The * value is intended for ISVs like what you're doing, where you can't possibly know the value ahead of time.

Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.