Deploying Your Rich Internet Application Nice And Easy!

You've developed this cool web site with snazzy Java rich internet applications that are certain to wow the end user. Now, the million dollar question - will your rich internet applications (RIA - applet or Java Web Start application) start up quickly and run consistently across all browsers and operating systems?

Do you wish you could determine the end user's browser, or Java Runtime Environment (JRE) version and customize the user experience based on that? Wouldn't it be nice if you could deliver the same user experience irrespective of the user's environment?

Recent improvements in the browser's Java Plug-in, support for applet deployment with JNLP, and the Deployment Toolkit, can help you build a web site that is robust and has a custom, well thought out user experience for every end user environment.

The Java One presentation, "Deploying Java Technologies To The Masses" By Thomas Ng, provides valuable insight into how Java Deployment technology can be leveraged to easily deploy rich internet applications. This blog highlights some of the deployment tips using examples.

Consider this scenario - You have a web site called "Design Your Home" that lets end users design their home by creating a floor plan and picking various interior decoration options. You have developed some very cool applets that let users drag and drop widgets, make choices and see their dream home being built...virtually. :-)

You are of course, a wordly-wise developer who knows that folks have various versions of operating systems, browsers and JREs running on their computers. Your applets need at least JRE version 1.6.0_10 (Java SE 6 u 10) to run correctly. So you've built a couple of different versions of the functionality to accommodate older environments. And as far as possible, you want the user to have a smooth un-interrupted experience on your web site. You also want to applets to load up quickly so that users don't get frustrated by slow loading web pages.

Let's explore several ways to improve performance and user experience and see how deployment technologies can be used to accomplish this goal. See the Related Reading section for other deployment related information.

Reducing your RIA's download time

The time it takes to download a RIA, depends on the size of your RIA jar file (DynamicTreeDemo.jar is the RIA's jar file in this example). Deploy pack200 compressed jar files as shown below.

  • Compress the jar file using the pack200 tool
    // compresses DynamicTreeDemo.jar to produce DynamicTreeDemo.jar.pack.gz
    $ pack200 DynamicTreeDemo.jar.pack.gz DynamicTreeDemo.jar
  • Set the jnlp.packEnabled property in the JNLP file
    // add the jnlp.packEnabled property in the JNLP file for the RIA
        <!-- Application Resources -->
    		<j2se version="1.6+"
    				max-heap-size="128m" />
    		<jar href="DynamicTreeDemo.jar" main="true"/>
    		<property name="jnlp.packEnabled" value="true"/>

    When the jnlp.packEnabled property is set, the Java Plug-in looks for the appropriate jar file with the .pack.gz extension (e.g. DynamicTreeDemo.jar.pack.gz). If found, the Java Plug-in automatically unpacks and loads the jar file. If a file with the .pack.gz extension is not found, then it attempts to load the jar file itself (e.g. DynamicTreeDemo.jar).

    If you plan to sign your RIA, pack first and then sign.

  • Remove unnecessary white space from the JNLP file and JavaScript files.
  • Optimize images and animation to reduce download time.

Note: You need to deploy your RIA on a web server to use / test this property

Improving start up time by avoiding unnecessary update checks

RIAs are cached locally to improve start up time. However, before launching the RIA, the Java Plug-in checks to make sure that every jar file referenced in the JNLP file is up-to-date. In other words, the Java Plug-in 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.

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

  • Rename the jar files to include a version number suffix
    naming convention - <jar file name> "__V" <version number> ".jar"
    example - DynamicTreeDemo__V1.0.jar		 		 
  • In the JNLP file, specify a version for every jar file. Set the jnlp.versionEnabled property to true.
        <!-- Application Resources -->
    		<j2se version="1.6+"
    				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"/>

    When the jnlp.versionEnabled property is enabled, the Java Plug-in performs only one update check to make sure the JNLP file is up-to-date. It compares the version numbers specified in the JNLP file with the corresponding jar file versions (per the naming convention mentioned above) and updates only the outdated jar files. This is efficient because only the update check for the JNLP file happens over the network. All other version checks happen locally.

    If a file with the correct version number is not found, the Java Plug-in attempts to load the default jar file (e.g. DynamicTreeDemo.jar).

If it is not critical for the user to immediately run the latest version of your RIA, you may run the update check in the background. The newer version will be launched the next time the user uses your RIA. Add the following to your JNLP file:

<update check='background'/>


  • When using jnlp.versionEnabled and jnlp.packEnabled properties together, rename the packed jar file per the version protocol naming convention (e.g. DynamicTreeDemo__V1.0.jar.pack.gz)
  • You need to deploy your RIA on a web server to use / test this property

Signing RIAs only when necessary

Signed RIAs will display security warnings to the user. When trying to access a simple RIA, security dialogs may unnerve users and turn them away from the application. So, sign only if you need to (for example, when accessing native libraries)

Recent enhancements to RIA security model eliminate the need to sign your RIA in the following cases:

  • Accessing services on web sites other than the RIA's own domain - The Java Plug-in has support for cross domain policy files. This means that if the third-party site allows access from other domains, then your unsigned RIAs can invoke services from these sites
  • Setting trusted VM arguments - You do not need to sign your RIA to pass secure VM arguments. You can set secure VM arguments in the JNLP file or specify them directly in the java_arguments parameter in the applet tag. Examples of secure VM arguments include maximum heap size, sun.java2d.noddraw, javax.swing.defaultlf etc.
  • Setting system properties used by your RIA only - You may need to set some system properties that only your RIA needs to use. If the name of the system property begins with jnlp. then you do not need to sign your RIA.

Preloading your Java Web Start application

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>

Ensuring that the correct version of Java is installed on the client

With the Deployment Toolkit, you have at least two ways to handle this.

  1. You can check and make sure users have or install the latest JRE as soon as they land on your web site, or,
  2. You can let them surf the site, and check and get the latest JRE only when they attempt to use your rich internet application.

Let's explore each option. To use the Deployment Toolkit, the client's browser should have JavaScript enabled.

Checking and installing the latest JRE as soon as the user lands on your web site

The example below checks if a user has JRE version 1.6.0_13 or greater installed. If not, it installs the latest JRE.

<script src=""></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 from.

Installing correct JRE only when the user attempts to use your RIA

If you deploy your rich internet application using the Deployment Toolkit, you do not have to take any additional steps to ensure that the client has a specific JRE version. The functions described below also deploy your RIA using the correct HTML tags (applet, object, embed), depending on the user's environment.

Use the runApplet function to deploy an applet, as shown in the example below. The last parameter to the runApplet function is the minimum version required to the run your applet.

    <script src=""></script>
			var attributes = { code:'components.DynamicTreeApplet',  width:300, height:300};
			var parameters = {jnlp_href: 'dynamictree-applet.jnlp'};
			deployJava.runApplet(attributes, parameters, '1.6');

To deploy as a Java Web Start application, use the createWebStartLaunchButton function with the correct minimum version parameter.

    <script src=""></script>
        var url = "dynamictree-applet.jnlp";
        deployJava.createWebStartLaunchButton(url, '1.6.0');

The runApplet and createWebStartLaunchButton functions check the client's version of Java. If the minimum version is not installed, they install the latest version of Java.

Customizing RIA's splash screen

You can customize the splash screen for your RIA. This ensures a consistent RIA loading experience across all platforms.

For Java based RIAs, specify the image attribute to customize the splash screen.

    <script src=""></script>
			var attributes = {code:'components.DynamicTreeApplet',  width:300, height:300};
			var parameters = {jnlp_href: 'dynamictree-applet.jnlp', 
                   			image: 'dukeanimated.gif'};
			deployJava.runApplet(attributes, parameters, '1.6');

For Java FX based RIAs, specify the loading_image_url and related attributes as shown below

    <script src=""></script>
           archive: "BouncingBall.jar",
           width: 240,
           height: 320,
           code: "bounce.Main",
           name: "BouncingBall",
           loading_image_url: "loading.gif",
           loading_image_height: 100,
           loading_image_width: 100

Java FX Packager

If you are building a Java FX application, use the Java FX Packager to deploy your application. The Java FX Packager accepts a few user options and automatically

  • compiles the Java FX source code
  • generates, signs and packs jar files
  • generates JNLP and HTML files

With these neat tools and tips, you should be able to deploy your rich internet applications flawlessly and efficiently across multiple platforms.

Related Reading

Please let us know if you'd like more information on specific topics. As always, we welcome feedback!

-- Sowmya Kannan

Post a Comment:
  • HTML Syntax: NOT allowed

Blog about Java technology documentation and news about Java releases.


« June 2016