31 Java Rich Internet Applications Enhancements in JDK 7

• The Exception Site List feature provides a way for users to run Java applets and Java Web Start applications that do not meet the latest security requirements. RIAs that are hosted on a site in the exception site list are allowed to run with the applicable security prompts. See Chapter 27, "Exception Site List" for information.

• Unsigned and self-signed RIAs are blocked when the security level is set to Very High or High.

• The Permissions attribute is required in the JAR file manifest of the main JAR file when the security level is set to Very High or High.

• JAR file manifest attributes are available to enhance the security of running Java applets and applications in a browser. The Application-Name attribute provides a secure title for your RIA. The Application-Library-Allowable-Codebase identifies the locations from which your RIA can be started if the JNLP file or HTML page is in a different location than the JAR file. The Caller-Allowable-Codebase attribute identifies the locations from which JavaScript code can call methods in your RIA. See Chapter 24, "JAR File Manifest Attributes for Security" for more information.

• The Java Control Panel has an option for restoring the security prompts that were hidden when the option to not show the prompt again was selected. See Section 18.4, "Security" for information about the Security tab of the Java Control Panel.

• For enterprises that provide a common execution environment and manage the applications that employees access, the Deployment Rule Set feature enables the creation of rules that allow some applications to be run without security prompts while automatically blocking other applications. This feature is intended to be used internally in an organization. See Chapter 26, "Deployment Rule Set" for more information.

• When a RIA is started, the JRE is checked to see if it is expired or below the security baseline. If so, the user is warned and given the opportunity to upgrade the JRE. For enterprises that manage the update process of user's systems, the deployment.expiration.check.enabled property can be set to suppress this check. See Chapter 19, "Deployment Configuration File and Properties" for more information.

In addition, Chapter 22, "Rich Internet Application Deployment Process" provides a look at how the deployment of RIAs is handled.

• Before Java applets and Java Web Start applications are run, the signing certificates are checked to ensure that one hasn't been revoked. Advanced options in the Java Control Panel can be set to manage if the checking is done and what services are used for making the checks. The default is now to check all certificates using both OCSP and CRLs. See Section 18.5.9, "Perform certificate revocation checks on" and Section 18.5.10, "Check for certificate revocation using" for more information.

• Permissions and Codebase are new attributes for the JAR file manifest that are used to defend RIAs against unauthorized code repurposing. These attributes are used with signed JAR files for applets and Java Web Start applications. See Section 24.9, "Preventing RIAs from Being Repurposed" for more information on these attributes. Steps 2 and 3 in the Deploying an Applet and Deploying a Java Web Start Application lessons in the Java Tutorial describe how to include these attributes in the manifest.

In addition, the Section 21.5, "Security Dialogs" section provides information on the prompts that are shown when a RIA is started, and Deployment Best Practices in the Java Tutorial provide suggestions for deploying your RIA.

• RIAs prompt the user for permission to run the first time the RIA is launched. The prompt includes information on the certificate used to sign the application, the location of the application, and the level of access that the application requests. In most cases, users can turn off the prompts for future launches of the same application. See What should I do when I see a security prompt from Java? for a description of the prompts.

• RIAs that are signed with a certificate issued by a recognized certificate authority require a single click by the user to run the application. Self-signed and unsigned applications require additional steps by the user before the application is launched. Therefore, for the best user experience, sign your RIAs with a trusted certificate before deploying to the end user. For information on signing JAR files, see Signing and Verifying JAR Files.

• Depending on the security level set in the Java Control Panel and the user's version of the JRE, self-signed or unsigned applications might not be allowed to run. The default setting of High permits all but local applets to run on a secure JRE. If the user is running an insecure JRE, only applications that are signed with a certificate issued by a recognized certificate authority are allowed to run.

  The Low and Custom settings are no longer available.

  For more information, see Chapter 18, "Security."

• Sandbox applications (previously called "unsigned" or "untrusted" applications) are restricted to the security sandbox. Privileged applications (previously called "signed" applications) are provided unrestricted access to a user's system.

  For Java Web Start applications, including applets that are launched using JNLP, the security element in the .jnlp file is used to set the level of access. If the element is not present, access is restricted to the sandbox. See Security in Rich Internet Applications for more information.

  For applets that are not launched using JNLP, the permissions element is added to the applet or object element to set the level of access to either sandbox or all-permissions. See Deploying With the Applet Tag for more information.

• JavaScript code that calls code within a privileged applet (an applet that runs outside the sandbox) is treated as mixed code. Warning dialogs are raised if the signed JAR files are not tagged with the Trusted-Library attribute. See Chapter 25, "Mixing Privileged Code and Sandbox Code" for more information.

For more information, see Chapter 21, "Setting the Security Level of the Java Client" and Chapter 18, "Java Control Panel.".

• Chapter 8, "Packaging for Distribution on a Mac"

• JDK 8 and JRE 8 Installation Guide which includes the Mac Install FAQ

• Java SE includes JavaFX: JDK 7 Update 2 and later includes the JavaFX SDK. See JavaFX 2.0.2 Release Notes for more information.

• Non-blocking installation of JRE and JavaFX using Deployment Toolkit: The web page continues to accept user input while Deployment Toolkit downloads and installs the required components. See 7052499 for details.

• Reduced footprint of signed JAR files: This release provides a new signing method that enables you to sign a JAR file as one large object instead of signing every JAR entry individually. This saves up to 10% of the total JAR size. Note: Users must run JRE 7 Update 2 or later to be able to use these JARs. See 7049193 and the section Sign the JAR Files in Packaging (the information in this section also applies to Java SE).

• Caching certificate details in the JNLP file for signed applications: For an application that uses security, a security dialog will present the cached certificates immediately for user approval while downloading the application in the background. An older JRE will ignore this functionality; it will present the certificate information after the application is downloaded. See 7049169 and the section Embed Signing Certificate into Deployment Descriptor in Packaging (the information in this section also applies to Java SE).

• Caching enabled by default: Caching of network content for application code running in Web Start mode is now enabled by default. This allows application improved performance and consistency with applet execution mode. To ensure the latest copy of content is used, the application can use URLConnection.setUseCaches(false) or request header Cache-Control values no-cache/no-store.

• Embedded JNLP support for Web Start: The Deployment Toolkit can use a copy of a JNLP file embedded into a web page to launch an application. This helps to reduce number of network connections needed for the first start of a Web Start application from the browser. See 7052492 and the section Embed Deployment Descriptor into Web Page in Packaging (the information in this section also applies to Java SE).

• Ability to pass secure JVM arguments to the Web Start application from inside the web page using Deployment Toolkit: This helps to avoid JVM relaunch due to JVM configuration mismatch and also helps to pass dynamic parameters from the web page. See 7072364 and the section Platform in Deployment in the Browser (the information in this section also applies to Java SE).

• Improvements for handling content with gzip encoding: The deployment cache will keep application content in compressed form and return it to the application as-is with gzip content-encoding in the HTTP header. This makes behavior more consistent across different execution modes (first launch versus subsequent launch, cache enabled versus cache disabled). See 6575586 for more details.

• Improved support for JNLP applications: JavaFX applications are more cleanly uninstalled; see 7085171 and 7053087. Recognition of JNLP install hints is improved; see 7046670.

• Startup improvements: Startup has been improved for specific scenarios; see 7099086 and 7098160 for details.

• New setting, Insecure JRE versions, in Java Control Panel: If users have a version of Java on their system that is below the security baseline, a warning message is displayed before an application or an applet can be run using that version. You can control this warning message with the Java Control Panel Advanced tab setting, Insecure JRE versions, which will set the property deployment.insecure.jres in the deployment.properties file to one of the following values:

  Value of deployment.insecure.jres property	Value of Insecure JRE versions setting	Description
  NEVER	Do not use insecure JRE versions	Untrusted content will always run with the default JRE.
  PROMPT	Prompt user before using insecure JRE versions	Users will see warning dialogs; this is the default value.
  ALWAYS	Allow using insecure JRE versions (not recommended)	Untrusted content will run with the requested JRE without any prompting.

  
  

  See Chapter 19, "Deployment Configuration File and Properties" for more information about the deployment.properties file.

• The following enhancements have been made to the syntax of JNLP files; see JNLP File Syntax:

  • The os attribute in the information and resources elements can now contain specific versions of Windows, such as Windows Vista or Windows 7.

  • Applications can use the install attribute in the shortcut element to specify their desire to be installed. Installed applications are not removed when the Java Web Start cache is cleared, but can be explicitly removed using the Java Control Panel.

  • Java Web Start applications can be deployed without specifying the codebase attribute; see Deploying Without Codebase

• A JNLP file can be embedded into an HTML page; see Embedding JNLP File in Applet Tag.

• You can check the status variable of the applet while it is loading to determine if the applet is ready to handle requests from JavaScript code; see Handling Initialization Status With Event Handlers.

• You now have control of the window decoration style and title of an applet launched from a shortcut or dragged out of the browser; see Requesting and Customizing Applet Decoration in Developing Draggable Applets.

• In order to make it easier to re-distribute an application that is deployed using a signed jar file, a JNLP template can be used. The JNLP template allows the developer to specify what parts of a JNLP file may be changed without resigning the main jar. For more information, see Section 15.2, "Signing a JAR File with a JNLP Template."

In addition, the following enhancements are introduced:

Area: DeploymentStandard/Platform: JDK 7Synopsis: Previously, the pack200 tool segmented its output by default. As of this release, the pack200 tool will create one large segment per jar file. Therefore, if deployers have jar files larger than the virtual memory available on the end-user's systems, it is recommended that either the input jar file be split, or suitably segmented by using the command-line flag "--segment-limit=nnnnn" or the equivalent property "SEGMENT_LIMIT".RFE: 6575357

Area: DeploymentStandard/Platform: JDK 7Synopsis: On Windows XP machines, the default cache directory is now under $USER\Local Settings\Application Data\Sun\Java\Deployment\cache. If needed, you may customize it to point to a network share folder for a single application cache across domain machines.RFE: 7012538

Area: DeploymentStandard/Platform: JDK 7Synopsis: The optional applet parameter, jnlp_embedded, provides the option to cache JNLP content on the HTML page and shortens applet launch time by skipping network access. The jnlp_embedded parameter has as its value the base64 encoded content of the applet JNLP file. For example:

<applet width="710" height="540" >
 <param name="jnlp_href" value="launch.jnlp"/>
 <param name="jnlp_embedded"
 value="PD94bWwgdmVyc2lvbj0iMS4wIiB . . . dC1kZXNjPg0KPC9qbmxwPg0K"/>
 <param name="draggable" value="true"/>
</applet>

When present, the jnlp_embedded parameter value replaces the content of the JNLP value pointed to by the jn.p_href parameter. The value of jnlp_ref is then optional and only used as a backup when the content of jnlp_embedded is invalid. There are a few restrictions on the embedded JNLP content:

• The attribute href from element jnlp should be relative.

• The attribute codebase from element jnlp should be empty (which means the codebase value will be derived from the document base URL).

RFE: 6990877

Area: DeploymentStandard/Platform: JDK 7Synopsis: As of JDK 7, clearing the cache works as follows:

• Only non-installed resources are removed from the cache when invoking javaws -XClearCache.

• Both installed and non-installed resources are removed by invoking javaws -uninstall.

• The "Delete Temporary Files" dialog, in JCP, previously had two checkboxes, both checked by default: "Applications and Applets", and "Trace and Log files". As of JDK 7, there will be three checkboxes, with the first two checked by default: "Trace and Log Files", "Cached Applications and Applets", and "Installed Applications and Applets".

• Only installed applications will have an entry in the Add/Remove panel.

RFE: 6873615

Area: JNLP FilesStandard/Platform: JDK 7Synopsis: In order to support debugging of Java Web Start applications, the -XX:HeapDumpOnOutOfMemoryError flag is now supported in JNLP files for trusted applications.RFE: 6664424

Area: JNLP FilesStandard/Platform: JDK 7Synopsis: Previous versions of Java Web Start did not correctly implement section 6.0.10 of the JNLP Specification. With this fix, fine-grained values for the "os" attribute, such as os="Windows\ XP", os="Windows\ Vista", and os="Windows\ 7", will work as expected. Values such as os="Win", and os="Windows" will continue to match all Windows platforms. As of this release, os="Windows\ Vista Windows\ 7" will only match Vista or Windows 7 and not Windows XP.RFE: 7014170

Area: PluginStandard/Platform: JDK 7Synopsis: A message stating that the first generation of the Java plugin is deprecated is now printed to the log file and to the Java console whenever plugin 1 is used.RFE: 7027792

Area: PluginStandard/Platform: JDK 7Synopsis: On Windows, the tray icon is now disabled by default. To enable the tray icon, use the Windows Start menu.RFE: 6694710

Area: PluginStandard/Platform: JDK 7Synopsis: The 64-bit toolkit is now supported on 64-bit Windows platforms.RFE: 6492139

Area: PluginStandard/Platform JDK 7Synopsis: Previously, the persistence API provided only temporary persistence for applets. When the VM exited, the data was lost. Data can be persisted via any of the standard Java mechanisms, through the use of LiveConnect to store data in the page DOM, or using one of the JNLP services.RFE: 6992419

Area: PluginStandard/Platform: JDK 7Synopsis: Google Chrome is now supported by the DT Plugin.RFE: 6907245