5.4 Deployment In-Depth

«« Previous
Next »»

Rich Internet application (RIA) deployment involves various technologies and tools such as the Java Network Launch Protocol (JNLP), Deployment Toolkit, pack200, jarsigner and so on. This lesson explores how these technologies and tools help developers deploy RIAs (applets and Java Web Start applications).

The main components that are involved in RIA deployment are the following:
  • The HTML page in which the RIA will be deployed
  • The JNLP file for the RIA
  • The JAR file containing the class files and resources of the RIA
These components are referred to in subsequent topics.

User Acceptance of RIAs


For security, users are prompted for permission to run an RIA before launching for the first time, even if the application is signed or doesn't require access outside of the security sandbox. The prompt includes the following information, depending on the RIA being run:
  • Name of the RIA, or notification that the application is unsigned.
  • Information about the publisher, if the app is signed with a certificate from a trusted authority. If the certificate is expired, a warning is included. If the application is self-signed, the publisher is shown as UNKNOWN.
  • Warnings if the certificate is expired, revoked, or the revocation status cannot be checked.
  • Location from which the application is accessed.
  • Level of access required by the application. Limited access restricts the application to the security sandbox, unrestricted access provides the application with access to resources on the user's system.
  • Warning about missing JAR file manifest attributes if recommended attributes are not present.
  • For unsigned or self-signed applications, a checkbox that the user must select to accept the application.
  • In some cases, the option to not show the prompt again.
Users are also warned if they are running an out-of-date JRE and are given the opportunity to update to the latest version before running an application. Users can also choose to run with the JRE on their system, or to block the application from running.

The security level setting in the Java Control Panel determines if users are given the opportunity to run RIAs. The default setting of High prompts users for permission to run applications that are signed with a valid certificate and include the Permissions attribute in the manifest for the main JAR file. If the revocation status of an application cannot be checked, the application is also allowed to run with the user's permsision.

Signing your RIA provides the user with a level of trust. Consider the following when preparing your application for deployment:
  • The best user experience is provided by an application that is signed with a certificate issued by a recognized certificate authority.
  • Self-signed and unsigned applications are not allowed to be run unless an exception site list or deployment rule set has been created to explicitly allow the application to run.
  • Signed applications can be either privileged applications or sandbox applications. Privileged applications are provided unrestricted access to resources on the user's system. Sandbox applications are restricted to the Java security sandbox. Unsigned applications are restricted to the sandbox.

Deployment Toolkit


The Deployment Toolkit script is a set of JavaScript functions that can help developers deploy rich Internet applications (RIAs) consistently across various browser and operating system configurations. The Deployment Toolkit script evaluates the underlying browser and operating system, and deploys the RIA with the correct HTML. This script can also ensure that the required version of the Java Runtime Environment (JRE) software is present on the client machine. The Deployment Toolkit script was introduced in the Java Platform, Standard Edition 6 update 10 release.

Location of Deployment Toolkit Script

The Deployment Toolkit script exists at the following web addresses:
  • http://www.java.com/js/deployJava.js (See note.)
  • https://www.java.com/js/deployJava.js – When deploying your applet on a secure page, use the Deployment Toolkit script from this secure location to avoid mixed content warnings when the page is loaded.
Note: The http://www.java.com/js/deployJava.js web address is being phased out. Use the https://www.java.com/js/deployJava.js web address to launch all apps.

The JavaScript code in this location has been minimized so that it can load quickly. You can view the human readable version of the JavaScript code with associated comment blocks at https://www.java.com/js/deployJava.txt.

Note: The JavaScript interpreter should be enabled in the client's browser so that the Deployment Toolkit script can run and deploy your RIA properly.


Deploying an Applet


You can deploy applets by using the runApplet function of the Deployment Toolkit script. The runApplet function ensures that the required minimum version of the Java Runtime Environment (JRE) software exists on the client and then runs the applet. The runApplet function generates an HTML <applet> tag with the information provided.

Note: Depending on the type of browser, you might be unable to view the HTML generated by the Deployment Toolkit script when you try to view the source for the web page. To view the generated HTML, try saving the HTML page after it has been loaded, or use a tool such as Firebug (a Mozilla Firefox add-on).

You can deploy applets by specifying the deployment options as attributes and parameters of the <applet> tag. You can also specify deployment options in a Java Network Launch Protocol (JNLP) file to take advantage of advanced features. See the Java Network Launch Protocol topic for more information about this protocol.

Note: If the client does not have the required minimum version of the JRE software, the Deployment Toolkit script redirects the browser to http://www.java.com to allow users to download the latest JRE software. On some platforms, users might be redirected before they can view the web page containing the applet.

The parameters to the runApplet function vary depending on whether you are using JNLP. Applets deployed by using JNLP can run only if the next generation Java Plug-in software exists on the client machine (the next generation Java Plug-in software was introduced in the Java Platform, Standard Edition 6 update 10 release).

The next section shows how to use the runApplet function in the HTML page that will display the applet. The following usage scenarios are described:
  • Specifying deployment options as attribute and parameter name-value pairs
  • Using the jnlp_href parameter to specify deployment options in a JNLP file
  • Specifying attribute and parameter name-value pairs as well as a JNLP file (enables applet to run on the old and next generation Java Plug-in software)
Function signature: runApplet: function(attributes, parameters, minimumVersion)

Parameters:
  • attributes – The names and values of the attributes of the generated <applet> tag
  • parameters – The names and values of the <param> tags in the generated <applet> tag
  • minimumVersion – The minimum version of the JRE software that is required to run this applet
Usage:
  • Specifying deployment options as attribute and parameter name-value pairs
The attributes and parameters passed as name-value pairs are written out as attributes and nested <param> tags in the generated <applet> tag. Applets deployed in this manner can be run by the old Java Plug-in software.

// launch the Java 2D applet on JRE version 1.6.0
// or higher with one parameter (fontSize)
<script src=
    "https://www.java.com/js/deployJava.js"></script>
<script>
    var attributes = {code:'java2d.Java2DemoApplet.class',
        archive:'Java2Demo.jar', width:710, height:540};
    var parameters = { fontSize:16, permissions:'sandbox' };
    var version = '1.6';
    deployJava.runApplet(attributes, parameters, version);
</script>

Open DeployUsingNameValuePairs.html in a browser to view the the Java2D applet.
  • Using the jnlp_href parameter to specify deployment options in a JNLP file
The attributes and parameters (jnlp_href in this case) passed as name-value pairs are written out as attributes and nested <param> tags in the generated <applet> tag. Applets deployed in this manner can be run by the next generation Java Plug-in software only. It is better to specify the applet's width and height as attributes as follows:

<script src="https://www.java.com/js/deployJava.js"></script>
<script> 
    var attributes = { code:'java2d.Java2DemoApplet', width:710, height:540 }; 
    var parameters = { jnlp_href: 'java2d.jnlp' }; 
    deployJava.runApplet(attributes, parameters, '1.6'); 
</script>

Open DeployUsingJNLP.html in a browser to view the the Java2D applet.
  • Specifying attribute and parameter name-value pairs as well as a JNLP file
Applets deployed by using JNLP will run only if end users have the next generation Java Plug-in software running on their browsers. If you would like your applet to run on the old Java Plug-in software also, specify deployment options using attribute and parameter name-value pairs as well as a JNLP file.

<script src="https://www.java.com/js/deployJava.js"></script>
<script>  
    var attributes = {code:'java2d.Java2DemoApplet.class', 
            archive:'Java2Demo.jar', width:710, height:540}; 
    var parameters = { fontSize:16, jnlp_href:'java2d.jnlp' }; 
    var version = '1.6' ; 
    deployJava.runApplet(attributes, parameters, version);      
</script>

The following guidelines are helpful if some deployment options have different values in the attribute name-value pairs and in the JNLP file:
  • Specify width and height as attribute name-value pairs (not in the JNLP file).
  • Specify parameters such as image and boxbgcolor as parameter name-value pairs (not in the JNLP file). These parameters are needed early on in the applet startup process.
  • In the JNLP file, leave the codebase attribute empty or specify an absolute URL. When the codebase attribute is left empty, it defaults to the directory containing the JNLP file.
  • If the applet is launched using a JNLP file, the values for the code, codebase, and archive attributes are taken from the JNLP file. If these attributes are also specified separately as attribute name-value pairs, the attribute name-value pairs are ignored.
Open DeployUsingNameValuePairsAndJNLP.html in a browser to view the the Java2D applet.

Customizing the Loading Screen


A default loading screen is displayed when an applet is being loaded in the web page. You can display a customized splash screen by specifying the following parameters when you deploy the applet:
  • image - the image to be displayed in the splash screen
  • boxbgcolor - the background color of the area in which the applet will be displayed
  • boxborder - whether the applet should have a border; defaults to true
  • centerimage - the position of the image; defaults to false
The splash screen can display a static image or an animated gif.

The code snippet from AppletPage.html shows how to customize the splash screen to display an animation of the Duke, the Java mascot.

<script src="https://www.java.com/js/deployJava.js"></script>
<script> 
  var attributes = {code:'SwingSet2Applet.class',
      archive:'SwingSet2.jar', width:695, height:525} ; 
    <!-- customize splash screen display options -->
  var parameters = {jnlp_href: 'SwingSet2.jnlp', 
                    image: 'dukeanimated.gif', 
                    boxbgcolor: 'cyan', 
                    boxborder: 'true', 
                    centerimage: 'true'   
                    }; 
  deployJava.runApplet(attributes, parameters, '1.6'); 
</script>

Open AppletPage.html in a browser to view the splash screen when the SwingSet2 Demo applet is loaded. If you've clicked this link before and viewed the SwingSet2 Demo applet, make sure to clear your cache using the Java Control Panel. You may not see the splash screen if the applet loads quickly.

Note:  If you don't see the example running, you might need to enable the JavaScript interpreter in your browser so that the Deployment Toolkit script can function properly.


Embedding JNLP File in Applet Tag


When applets are deployed by using the Java Network Launch Protocol (JNLP), the Java Plug-in software launches the applet after downloading the JNLP file from the network. Beginning in the Java SE 7 release, you can reduce the the time it takes for applets to launch, by embedding the JNLP file in the web page itself so that an additional network request can be avoided the first time the applet is loaded. This will result in applets launching quickly on the web browser.

A Base64 encoded JNLP file can be embedded in the jnlp_embedded parameter when deploying an applet in a web page. The attributes of the <jnlp> element should meet the following restrictions:
  • The href attribute should contain a relative path.
  • The codebase attribute should not be specified. This implies that the codebase will be derived from the URL of the web page in which the applet is loaded.
The following steps describe how to embed a JNLP file in a web page to deploy an applet.

1. Create a JNLP file for your applet. A sample file is shown next.
<?xml version="1.0" encoding="UTF-8"?>
<!-- href attribute contains relative path;
     codebase attribute not specified -->
<jnlp href="dynamictree_applet.jnlp">
    <information>
        <title>Dynamic Tree Demo</title>
        <vendor>Dynamic Team</vendor>
    </information>
    <resources>
        <!-- Application Resources -->
        <j2se version="1.7+" />
        <jar href=
            "dist/applet_ComponentArch_DynamicTreeDemo/DynamicTreeDemo.jar" 
             main="true" />
    </resources>
    <applet-desc 
         name="Dynamic Tree Demo Applet"
         main-class="appletComponentArch.DynamicTreeApplet"
         width="300"
         height="300">
     </applet-desc>
     <update check="background"/>
</jnlp>

2. Encode the contents of the JNLP file using the Base64 scheme. You can use any Base64 encoding tool to encode the the JNLP file. Check the usage of the tool to create a string with Base64 encoding. Some examples of tools and web sites that may be used are as follows:
  • UNIX commands – base64, uuencode
  • Web sites – Base64 Encode and Decode, Base64 Encoder
3. When deploying the applet in a web page, specify the jnlp_embedded parameter with it's value set to the Base64 encoded JNLP string. Make sure to include only the actual Base64 bytes without any encoding tool specific headers or footers.

<script src="https://www.java.com/js/deployJava.js"></script>
<script>
    var attributes = {} ;
    <!-- Base64 encoded string truncated below for readability -->
    var parameters = {jnlp_href: 'dynamictree_applet.jnlp',
        jnlp_embedded: 'PCEtLSANCi8qDQogKiBDb ... bmxwPg=='
    } ;
    deployJava.runApplet(attributes, parameters, '1.6');
</script>

Some encoding tools may wrap the encoded string into several 76-column lines. To use this multi-line attribute value in JavaScript code, specify the attribute value as a set of concatenated strings. You can include the multi-line attribute value as is if the applet is deployed directly with the <applet> HTML tag.

Open AppletPage.html in a browser to view the Dynamic Tree Demo applet that is launched by using the JNLP file embedded in the web page.

Note:  If you don't see the example running, you might need to enable the JavaScript interpreter in your browser so that the Deployment Toolkit script can function properly.


Deploying a Java Web Start Application


You can deploy Java Web Start applications by using the createWebStartLaunchButton function of the Deployment Toolkit script. Java Web Start applications are launched using Java Network Launch Protocol (JNLP) The createWebStartLaunchButton function generates a link (HTML anchor tag - <a>) to the Java Web Start application's JNLP file.

This generated anchor tag is the Java Web Start application's Launch  button. When the end user clicks the Launch button, the Deployment Toolkit script ensures that the appropriate Java Runtime Environment (JRE) software is installed and then launches the Java Web Start application.

Note: Depending on the type of browser, you might be unable to view the HTML generated by the Deployment Toolkit script when you try to view the source for the web page. To view the generated HTML, try saving the HTML page after it has been loaded, or use a tool such as Firebug (a Mozilla Firefox add-on).

Note: If the client does not have the required minimum version of the JRE software, the Deployment Toolkit script redirects the browser to http://www.java.com to allow users to download the latest JRE software.

Function signature: createWebStartLaunchButton: function(jnlp, minimumVersion) or createWebStartLaunchButton: function(jnlp)

Parameters:
  • jnlp – The URL of the JNLP file containing deployment information for the Java Web Start application. This URL should be an absolute path.
  • minimumVersion – The minimum version of JRE software required to run this application
Usage:

Specifying a minimum version of JRE software that is required to run the application
<script src="https://www.java.com/js/deployJava.js"></script>
<script>
    var url = "http://java.sun.com/javase/technologies/desktop/javawebstart/apps/notepad.jnlp";
    deployJava.createWebStartLaunchButton(url, '1.6.0');
</script>
  • Enabling Java Web Start application to run on any JRE software version
Use the createWebStartLaunchButton: function(jnlp) function if your application does not have a minimum JRE software version requirement.

Note: When deploying by using any of the previously described createWebStartLaunchButton functions, you must specify an absolute codebase in the Java Web Start application's JNLP file. This enables the Java Web Start application to be launched from the command line with the javaws <path/to/local JNLP file> command.

Changing the Launch Button


You can change your Java Web Start application's Launch button image, if you don't like the default Launch button  or if you have another image that you have standardized on.

Use the deployJava.launchButtonPNG variable to point to the location of your Launch button's image.

Variable: deployJava.launchButtonPNG

Usage: Providing an alternate image URL

In this example, the Notepad application's Launch button is now an image of Duke waving.

<script src="https://www.java.com/js/deployJava.js"></script>
<script>
    deployJava.launchButtonPNG='https://docs.oracle.com/javase/tutorial/images/DukeWave.gif';
    var url = "https://docs.oracle.com/javase/tutorialJWS/deployment/webstart/examples/Notepad.jnlp";
    deployJava.createWebStartLaunchButton(url, '1.6.0');
</script>

The Notepad application's new Launch button (Duke waving) follows. Click on Duke's image to launch the Notepad application.

Note:  If you don't see the example running, you might need to enable the JavaScript interpreter in your browser so that the Deployment Toolkit script can function properly.

Deploying Without Codebase


Beginning in the Java SE 7 release, you do not have to specify an absolute path for the codebase attribute in the Java Web Start application's Java Network Launch Protocol (JNLP) file. You can develop and test your applications in different environments without having to modify the path in the codebase attribute. If no codebase is specified, the Java Web Start software assumes that the codebase is relative to the web page from which the Java Web Start application is launched.

The following functions of the Deployment Toolkit script can be used to deploy Java Web Start applications in a web page when the JNLP file does not contain the codebase attribute:
  • launchWebStartApplication – Use this function in an HTML link to deploy your Java Web Start application.
  • createWebStartLaunchButtonEx – Use this function to create a Launch button for your Java Web Start application.
Note: To run, Java Web Start applications deployed by using the previously specified functions require at least the Java SE 7 release. If the client does not have at least the Java SE 7 release, the functions instruct the user to install the required Java Runtime Environment (JRE) software before launching the Java Web Start application.
Function signature: launchWebStartApplication: function(jnlp)

Parameter:

jnlp – The path to the JNLP file containing deployment information for the Java Web Start application. This path can be relative to the web page in which the Java Web Start application is deployed.

Usage:

In the following example, the launchWebStartApplication function is invoked in the href attribute of an HTML anchor (a) tag.

The dynamictree_webstart_no_codebase.jnlp JNLP file is used to deploy the Dynamic Tree Demo application.

<script src="https://www.java.com/js/deployJava.js"></script>
<a href="javascript:deployJava.launchWebStartApplication('dynamictree_webstart_no_codebase.jnlp');">Launch</a>

The Java Web Start application is launched when the user clicks the resulting HTML link.

Function signature: createWebStartLaunchButtonEx: function(jnlp)

Parameter:

jnlp – The path to the JNLP file containing deployment information for the Java Web Start application. This path can be relative to the web page in which the Java Web Start application is deployed.

Usage:

The following example shows the usage of the createWebStartLaunchButtonEx function.

The dynamictree_webstart_no_codebase.jnlp JNLP file is used to deploy the Dynamic Tree Demo application.

<script src="https://www.java.com/js/deployJava.js"></script>
<script>        
    var jnlpFile = "dynamictree_webstart_no_codebase.jnlp";
    deployJava.createWebStartLaunchButtonEx(jnlpFile);
</script>

The Java Web Start application is launched when the user clicks the resulting Launch button.

Open JavaWebStartAppPage_No_Codebase.html in a browser to view the Dynamic Tree Demo application that is deployed by using the functions described in this topic.

Note: You can also launch the Java Web Start application at the system command prompt by invoking the javaws command with the complete url of the JNLP file as shown in the following code snippet.

javaws http://example.com/dynamictree_webstart_no_codebase.jnlp


Checking the Client JRE Software Version


There are many reasons to check if a particular version of the Java Runtime Environment (JRE) software is available on a client machine. For example, you might want to launch a different version of your rich Internet application (RIA) or redirect the user to a different page depending on the client's JRE software version.

Use the Deployment Toolkit script's versionCheck function to check if a particular version or range of JRE versions is installed on the client.

Function signature: versionCheck: function(versionPattern)

Parameters:
  • versionPattern – String specifying the version or range of versions to check for, such as such as "1.4", "1.5.0*" (1.5.x family), and "1.6.0_02+" (any version greater than or equal to 1.6.0_02).
Usage: Creating a different user experience depending on the client's JRE software version

In this example, a Launch button is created for the Notepad application only if the version of JRE software on the client is greater than or equal to 1.6. If not, the browser is redirected to oracle.com.

<script src="https://www.java.com/js/deployJava.js"></script>
<script>
    if (deployJava.versionCheck('1.6+')) {            
        var url = "https://docs.oracle.com/javase/tutorialJWS/deployment/webstart/examples/Notepad.jnlp";
        
        <!-- you can also invoke deployJava.runApplet here -->
        deployJava.createWebStartLaunchButton(url, '1.6.0'); 
    } else {
        document.location.href="http://oracle.com";
    }
</script>        
Note: Depending on the client's operating system and version of the Java platform, you might be able to verify version information for JRE software at the major version level (for example, 1.6) or at a finer update level (for example, 1.6.0_10).

Java Network Launch Protocol


The Java Network Launch Protocol (JNLP) enables an application to be launched on a client desktop by using resources that are hosted on a remote web server. Java Plug-in software and Java Web Start software are considered JNLP clients because they can launch remotely hosted applets and applications on a client desktop. See Java Network Launching Protocol and API Specification Change Log for details.

Recent improvements in deployment technologies enable us to launch rich Internet applications (RIAs) by using JNLP. Both applets and Java Web Start applications can be launched by using this protocol. RIAs that are launched by using JNLP also have access to JNLP APIs. These JNLP APIs allow the RIAs to access the client desktop with the user's permission.

JNLP is enabled by a RIA's JNLP file. The JNLP file describes the RIA. The JNLP file specifies the name of the main JAR file, the version of Java Runtime Environment software that is required to run the RIA, name and display information, optional packages, runtime parameters, system properties, and so on.

You can find more information about deploying RIAs by using JNLP in the following topics:
  • Deploying an Applet
  • Deploying a Java Web Start Application
  • JNLP API
  • Structure of the JNLP File

Structure of the JNLP File


This topic describes the syntax of the Java Network Launch Protocol (JNLP) file for rich Internet applications (RIAs).

The following code snippet shows a sample JNLP file for a Java Web Start application:

<?xml version="1.0" encoding="UTF-8"?>
<jnlp spec="1.0+" codebase="" href="">
    <information>
        <title>Dynamic Tree Demo</title>
        <vendor>Dynamic Team</vendor>
        <icon href="sometree-icon.jpg"/>
        <offline-allowed/>
    </information>
    <resources>
        <!-- Application Resources -->
        <j2se version="1.6+" href=
           "http://java.sun.com/products/autodl/j2se"/>
        <jar href="DynamicTreeDemo.jar"
            main="true" />

    </resources>
    <application-desc
         name="Dynamic Tree Demo Application"
         main-class="webstartComponentArch.DynamicTreeApplication"
         width="300"
         height="300">
     </application-desc>
     <update check="background"/>
</jnlp>

The following table describes the elements and attributes commonly used in JNLP files. Click the parent link to view an element's parent.

Note: This table does not include all possible contents of the JNLP file

Commonly Used Elements and Attributes in a JNLP file

Element

Attributes
Description
Since
Required
jnlp
The topmost xml element for a JNLP file.
1.0
Yes
spec
Value of the attribute can be 1.0, 1.5, or 6.0, or can use wildcards such as 1.0+. It denotes the minimum version of the JNLP Specification that this JNLP file can work with.
1.0
codebase
The base location for all relative URLs specified in href attributes in the JNLP file.
1.0
href
The URL of the JNLP file itself.
1.0
version
The version of the RIA being launched, as well as the version of the JNLP file itself.
1.0
information parent
Contains other elements that describe the RIA and its source.
1.0
Yes
os
The operating system for which this information element should be considered.
1.5.0
arch
The architecture for which this information element should be considered.
1.5.0
platform
The platform for which this information element should be considered.
1.5.0

locale
The locale for which this information element should be considered.
1.5.0

       title parent
The title of the RIA.
1.0
Yes
 vendor parent

The provider of the RIA.
1.0
Yes
homepage parent

The homepage of the RIA.
1.0
href
A URL pointing to the icon file. Can be in one of the following formats: gif, jpg, png, ico.
1.0
Yes
kind
Indicates the suggested use of the icon, can be: default, selected, disabled, rollover, splash, or shortcut.
1.0

width
Can be used to indicate the resolution of the image.
1.0

height
The operating system for which this information element should be considered.
1.0
depth
Can be used to indicate the resolution of the image.
1.0
 offline-allowed parent

Indicates that this RIA can operate when the client system is disconnected from the network.
1.0
 shortcut parent
Can be used to indicate the RIA's preferences for desktop integration.
1.5.0

online
The topmost xml element for a JNLP file.
1.5.0

desktop parent

Can be used to indicate the RIA's preference for putting a shortcut on the user's desktop.
1.5.0
menu parent

Can be used to indicate the RIA's preference for putting a menu item in the user's start menus.
1.5.0
sub-menu
Can be used to indicate the RIA's preference for where to place the menu item.
1.5.0
  association parent

Can be used to hint to the JNLP client that the RIA wants to be registered with the operating system as the primary handler of certain extensions and a certain mime-type. If this element is included, either the offline-allowed element must also be included, or the href attribute must be set for the jnlp element.
1.5.0

extensions
A list of file extensions (separated by spaces) that the RIA requests it be registered to handle.
1.5.0

mime-type
The mime-type that the RIA requests it be registered to handle.
1.5.0
related-content parent

An additional piece of related content that can be integrated with the RIA.
1.5.0
href
A URL pointing to the related content.
1.5.0
Yes
  update parent

The preferences for how RIA updates should be handled by the JNLP client.
1.6.0


Encoding JNLP Files


Java Web Start software supports encoding of JNLP files in any character encoding supported by the Java platform. For more information about character encoding in the Java platform. To encode a JNLP file, specify an encoding in the XML prolog of that file. For example, the following line indicates that the JNLP file is encoded in UTF-16.

<?xml version="1.0" encoding="utf-16"?>
Note: The XML prolog itself must be UTF-8-encoded.

Deployment Best Practices


You can improve the user experience of your rich Internet application (RIA) using the best practices described in this topic.
  • Sign the RIA using a certificate from a recognized certificate authority. Make sure that all artifacts are signed, and that the certificate has not expired. 
  • Request the minimum level of permissions that is needed. If the RIA does not require unrestricted access to a user's system, specify the permission level to be sandbox.
  • Optimize the size of JAR files and related resources so that your RIA can load quickly. See Reducing the Download Time for optimization techniques.
  • Enable the version download protocol and use background update checks to enable your RIA to start quickly. 
  • Make sure that the client has the required version of the Java Runtime Environment software. See Ensuring the Presence of the JRE Software for details on how the Deployment Toolkit script can be used for this purpose.
  • Embed the contents of your applet's JNLP file in the <applet> tag to avoid loading the JNLP file from the network. This feature was introduced in the Java SE 7 release.
  • Preload your Java Web Start application, if possible. If you plan to deploy your RIA as a Java Web Start application in an enterprise where you have some administrative control, you can preload your application to various clients so that it is cached and ready to use. Use the following command to preload your Java Web Start application:
javaws -import -silent <jnlp url>


Reducing the Download Time


Rich Internet applications (RIAs) are downloaded from a web site when the user tries to access them. (RIAs can be cached after the initial download to improve performance). The time taken to download a RIA depends on the size of the RIA's JAR file. Larger JAR files take longer to download.

You can reduce the download time of your RIA by applying the following techniques:
  • Compress your RIA's JAR file by using the pack200 tool.
  • Remove unnecessary white space from the Java Network Launch Protocol (JNLP) file and the JavaScript files.
  • Optimize images and animation.
The following steps describe how to create and deploy a compressed JAR file for a signed RIA.

1. Normalize the JAR file using the --repack option.
This step ensures that the security certificate and JAR file will pass verification checks when the RIA is launched.

pack200 --repack DynamicTreeDemo.jar

2. Sign the normalized JAR file.

jarsigner -keystore myKeyStore DynamicTreeDemo.jar me

where myKeyStore is the name of the keystore and me is the alias for the keystore.

3. Pack the signed JAR file

pack200 DynamicTreeDemo.jar.pack.gz DynamicTreeDemo.jar    

4. Set the jnlp.packEnabled property to true in the RIA's JNLP file.

<resources>    
    <j2se version="1.6+"
        href="http://java.sun.com/products/autodl/j2se"
              max-heap-size="128m" />
    <jar href="DynamicTreeDemo.jar"
        main="true"/>
    <property name="jnlp.packEnabled"
        value="true"/>
    <!-- ... -->
</resources>

When the jnlp.packEnabled property is set in the JNLP file, the Java Plug-in software looks for the compressed JAR file with the .pack.gz extension (for example, DynamicTreeDemo.jar.pack.gz). If found, the Java Plug-in software automatically unpacks and loads the JAR file. If a file with the .pack.gz extension is not found, then the Java Plug-in software attempts to load the regular JAR file (for example, DynamicTreeDemo.jar).

Note: You need to deploy your RIA on a web server to test the jnlp.packEnabled property.

Avoiding Unnecessary Update Checks


Rich Internet applications (RIAs) are cached locally to improve startup time. However, before launching a RIA, the launch software checks to make sure that every JAR file referenced in the RIA's Java Network Launch Protocol (JNLP) file is up-to-date. In other words, the launch software makes sure that you are running the latest version of the RIA and not an older cached copy. These update checks can take up to a few hundred milliseconds depending on the number of JAR files and network speed. Use the techniques described in this topic to avoid unnecessary update checks and to enhance the start up time of your RIA.

Note: The term "launch software" is used here to collectively refer to the Java Plug-in software and the Java Web Start software. The Java Plug-in software launches applets while the Java Web Start software launches Java Web Start applications.

Leveraging the Version Download Protocol

You can leverage the version download protocol to eliminate unnecessary version checks. See the following steps to enable this protocol.

1. Rename the JAR files to include a version number suffix with the following naming convention:
    
    <JAR file name>__V<version number>.jar

For example, rename DynamicTreeDemo.jar to DynamicTreeDemo__V1.0.jar.
2. In the JNLP file, specify a version for every JAR file, and set the jnlp.versionEnabled property to true.
<resources>
    <!-- Application Resources -->
    <j2se version="1.6+"
        href="http://java.sun.com/products/autodl/j2se"
            max-heap-size="128m" />
    <jar href="DynamicTreeDemo.jar"
        main="true" version="1.0"/>   
    <jar href="SomeOther.jar" version="2.0"/>
    <property name="jnlp.versionEnabled"
        value="true"/>
    <!-- ... -->
</resources>

When the jnlp.versionEnabled property is enabled, the launch software performs only one update check to make sure that the JNLP file is up-to-date. The software compares the version numbers that are specified in the JNLP file with the corresponding JAR file versions (according to the naming convention mentioned in step 1) and updates only the outdated JAR files. This approach is efficient because only the update check for the JNLP file occurs over the network. All other version checks occur locally.

If a file with the correct version number is not found, the launch software attempts to load the default JAR file (for example, DynamicTreeDemo.jar).

Performing Update Checks in the Background

If it is not critical for the user to immediately run the latest version of your RIA, you can specify that all update checks should occur in the background. In this case, the launch software launches the locally cached copy for immediate usage and downloads a newer version of the RIA in the background. The newer version of the RIA will be launched the next time the user attempts to use your RIA. To enable background update checks, add the following line to your JNLP file:

<update check='background'/>
The following code snippet shows a sample JNLP file with the background update check enabled:

<?xml version="1.0" encoding="UTF-8"?>
<jnlp spec="1.0+" codebase="" href="">
    <information>
        <title>Applet Takes Params</title>
        <vendor>Dynamic Team</vendor>
    </information>
    <resources>
        <!-- Application Resources -->
        <j2se version="1.6+" href=
            "http://java.sun.com/products/autodl/j2se"/>
        <jar href="applet_AppletWithParameters.jar"
            main="true" />
    </resources>
    <applet-desc 
         name="Applet Takes Params"
         main-class="AppletTakesParams"
         width="800"
         height="50">
             <param name="paramStr" value="someString"/>
             <param name="paramInt" value="22"/>
     </applet-desc>
     <update check="background"/>
</jnlp>

Ensuring the Presence of the JRE Software


Rich Internet applications (RIAs) usually need a minimum version of the Java Runtime Environment (JRE) software to be present on the client machine. When deploying a RIA, you need to ensure that client machines have the required version of the JRE software so that your RIA can function well. With the Deployment Toolkit script, you have at least two ways to handle this requirement.
  • You can check the version of client JRE software as soon as users access your web site and install the latest version if necessary.
  • You can let users navigate the web site, and check and install the latest JRE only when they attempt to use your RIA.
Checking and Installing the Latest JRE Software When the User Accesses Your Web Site

The following example checks if a user has at least version 1.6.0_13 of the JRE software installed. If not, the code installs the latest JRE software. See inline comments in the code.

<script src="https://www.java.com/js/deployJava.js"></script>
<script>
    
    // check if current JRE version is greater than 1.6.0 
    alert("versioncheck " + deployJava.versionCheck('1.6.0_10+'));
    if (deployJava.versionCheck('1.6.0_10+') == false) {                   
        userInput = confirm(
            "You need the latest Java(TM) Runtime Environment. " +
            "Would you like to update now?");        
        if (userInput == true) {  
    
            // Set deployJava.returnPage to make sure user comes back to 
            // your web site after installing the JRE
            deployJava.returnPage = location.href;
            
            // Install latest JRE or redirect user to another page to get JRE
            deployJava.installLatestJRE(); 
        }
    }

</script>

Installing the Correct JRE Software Only When the User Attempts to Use Your RIA

When you specify the minimum version of the JRE software in the runApplet or createWebStartLaunchButton function, the Deployment Toolkit script makes sure that the required version of the JRE software exists on the client before running your RIA.

Use the runApplet function to deploy an applet, as shown in the following example. The last parameter of the runApplet function is the minimum version that is required to run your applet (version 1.6).
    
<script src="https://www.java.com/js/deployJava.js"></script>
<script>
    var attributes = { code:'components.DynamicTreeApplet',
        width:300, height:300};
    var parameters = {jnlp_href: 'dynamictree_applet.jnlp'};
    deployJava.runApplet(attributes, parameters, '1.6');
</script>
To deploy a Java Web Start application, use the createWebStartLaunchButton function with the correct minimum version parameter (version 1.6).

<script src="https://www.java.com/js/deployJava.js"></script>
<script>
    var url = "dynamictree_applet.jnlp";
    deployJava.createWebStartLaunchButton(url, '1.6.0');
</script>
The runApplet and createWebStartLaunchButton functions check the client's version of the JRE software. If the minimum version is not installed, the functions install the latest version of the JRE software.


Answers to Questions and Exercises: Deployment In-Depth


Questions

1. Question: What script contains functions to deploy applets and Java Web Start applications?
Answer: The Deployment Toolkit script contains JavaScript functions that can be used to deploy applets and Java Web Start applications.

2. Question: True or False: You should always sign your RIA just to be sure it will always work.
Answer: True: Unsigned RIAs are blocked for security reasons. Always sign your RIA with a valid certificate from a trusted certificate authority.

Exercises

1. Exercise: Write the JavaScript code to deploy the Exercise applet using the ex.jnlp file.
Answer:

<script src="https://www.java.com/js/deployJava.js"></script>
<script> 
    var attributes = {code:'Exercise', width:300, height:300} ; 
    var parameters = {jnlp_href: 'ex.jnlp'} ; 
    deployJava.runApplet(attributes, parameters, '1.6'); 
</script>

«« Previous
Next »»