New Deployment Policies for Java SE Customers

In releases prior to Java Runtime Environment (JRE) 5.0 Update 6, you could specify exactly which JRE release to deploy with Java applets, Java Network Launching Protocol (JNLP) applications, and standalone applications.

Starting with JRE 5.0 Update 6, you can no longer specify the exact JRE release in Java applets for the Windows platform.

You can still specify the exact JRE release in JNLP and standalone applications. If you are a developer writing JNLP or standalone applications, you will need to pay more attention to your deployment strategies (as described later in this document).

This document describes deployment policies and recommendations for developers related to this change.

Deployment Policies

Java Applets

Deployment policies for Java applets are listed below.

• Java applets can no longer request to run with a specific version of the JRE software for the Windows platform.

• Java applets are run using the latest version of the JRE software that is installed on the system.

• Java applets can continue to request to run with a minimal version of the JRE software.

• For migration purposes, there is a solution which allows a Java applet to request to run with the latest version of the JRE in the 1.3.1, 1.4.2, 5.0, or 6 family on the system. For more details, see Deploying Java^TM Applets With Family JRE^TM Versions in Java Plug-in for Internet Explorer

• Notes

  • The latest version of the JRE software on the system is updated periodically through the Java Update mechanism. Because the latest version of the JRE software is typically the most secure version available (containing the most up-to-date security fixes), applets can be run with minimum potential security risk.

  • Independent Software Vendors (ISVs) should target a minimal JRE version to run their applet(s) and ensure forward compatibility. More specifically, in a non-managed deployment environment, applets may run with different versions of the JRE software depending on on each system's configuration. For example, if an applet is targeted for JRE 5.0 or later, an ISV should make sure it does not rely on private Application Programming Interfaces (APIs) or runtime behaviors that only exist in JRE 5.0u7.

Java JNLP Applications

Deployment policies for JNLP applications are listed below.

• JNLP applications can request to run with a minimal version of the JRE software.

• Signed JNLP applications can request to run with a specific version of the JRE software.

• Unsigned JNLP applications can also request to run with a specific version of the JRE software. However, if that specific version is not the latest JRE version installed on the end user system, a security warning dialog will pop up informing the end user about potential security risks. The user must confirm the action before the application continues to launch

• JNLP applications are run with the latest version of the JRE software on the system that satisfies the requested version requirement.

• Notes

  • The JRE software on the system is updated periodically to the latest version through the Java Update mechanism. Because the latest version of the JRE software is typically the most secure version available (containing the most up-to-date security fixes), JNLP applications that do not request any specific version of the JRE software are run with minimum potential security risks.

  • Security vulnerabilities might appear in a specific version of the JRE software requested by a the JNLP application. ISVs must make sure they update their applications regularly to target a newer (and more secure) version of the JRE software for deployment.

  • If an ISV wants to avoid the display of a security warning dialog when their JNLP applications request a specific version of the JRE for deployment, they must sign their JNLP applications.

Standalone Applications

Deployment policies for standalone applications are listed below.

• Standard applications can request to run with a specific version of the JRE software that they bundle.

• The JRE software on the system is updated periodically to the latest version through the Java Update mechanism. However, standalone applications cannot take advantage of security updates deployed through Java Update as this mechanism neither updates nor changes the JRE software bundled in standalone applications.
• Security vulnerabilities might appear in a specific version of the JRE software bundled with the standalone application. ISVs must make sure they update their applications regularly to use a newer (and more secure) version of the JRE software for deployment.

• Standard applications can also request to run with the default version of the JRE software on the system. The default version is the highest JRE version available on the system.

• The JRE software on the system is updated periodically to the latest version through the Java Update mechanism. Standalone applications using the default JRE release can take advantage of security updates deployed through Java Update as this mechanism updates and changes the default JRE software on the system.

Recommendations for Developers

Deployment recommendations for various types of applications are described below.

For Developers Writing New Java Applications

• If the Java application is deployed in a browser environment:

  • Deploy applications as Java applets, knowing that these applets should target a minimal JRE version, with forward compatibility in mind. The latest version of the JRE software on the system will be used for execution, and the Java Update mechanism will keep the JRE software on the system up-to-date.

• If the Java application is deployed in a non-managed environment (that is, Internet, or hybrid – Internet/Intranet):

  • If it is not critical to use a specific version of the JRE software for deployment, deploy applications as Java applets or JNLP applications. The latest version of the JRE software on the system will be used for execution, and Java Update will keep the JRE software on the system up-to-date.

  • If it is critical to use a specific JRE version for deployment, deploy applications as JNLP applications or standalone applications.

• If the Java application is deployed in a tightly managed environment (such as Intranet only):

  • If it is not critical to use a specific JRE version for deployment, deploy applications as Java applets or JNLP applications. The latest version of the JRE software on the system will be used for execution, and system administrators are responsible for keeping the JRE software on their end user systems up-to-date.

  • If it is critical to use a specific JRE version for deployment, deploy applications as JNLP applications or standalone applications.

  • Although it may not be obvious to do so, developers can also deploy their applications as Java applets if it is critical to use a specific JRE version for deployment. Java applets are run using the latest version of the JRE software that is installed on the system. Since the system administrators in a managed environment have full control over software deployment on each system, they could dictate the latest version of the JRE software on each system to indirectly control what version of the JRE software Java applets would use.

For Developers with Already Deployed Java Applications

• For Java applications that are currently deployed as Java applets:

  • If it is not critical to use a specific version of the JRE software for deployment, continue to deploy such applications as Java applets, knowing that their applets should target a minimal JRE version, with forward compatibility in mind. The latest version of the JRE software on the system will be used for execution, and the Java Update mechanism will keep the JRE software on the system up-to-date.

  • If it is critical to use a version of the JRE software for deployment in the 1.3.1, 1.4.2, 5.0, or 6 family, and it is not critical to use a specific version within that family, update your Java applets to request to run with the latest version of the JRE in the family on the system. For more details, see Deploying Java^TM Applets With Family JRE^TM Versions in Java Plug-in for Internet Explorer

    • If the deployment is in a non-managed environment (that is. Internet, or hybrid – Internet/Intranet), the Java Update mechanism will only keep the highest family version of the JRE software on the system up-to-date. In other words, the end user is responsible for keeping any JRE software in an older family version on the system up-to-date.

    • If the deployment is in a tightly managed environment (that is, Intranet only), system administrators are responsible for keeping the JRE software in each family version on their end user systems up-to-date.

  • If it is critical to use a specific JRE version for deployment, developers should migrate their Java applications into JNLP applications. For more details, see Migrating Java Applets to Java Web Start Applications .

• If the Java applications are currently deployed as JNLP applications or standalone applications:

  • No change is required.

Using a Specific JRE Version for Deployment

A specific version of the JRE software may be used to run Java applets and applications in a secure fashion as long as that specific JRE version has not reached End of Service Life. Refer to the Sun End of Service Life (EOSL) Policy To continue benefiting from critical fixes for a JRE version after it has reached EOSL, you need a support contract or subscription from Sun.

Further Assistance

If you need further assistance to adopt these deployment policies, contact Sun Engineering Services for more details.

More Information

For more information, refer to Java^TM SE 6: Migrating Java Applets to Java Web Start Applications .