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:
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.
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:
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.
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.
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.
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.
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.
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
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.