An Oracle blog about the Java Tutorials

Deploying Your Rich Internet Application Nice And Easy!

Guest Author

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

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

  • 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="http://java.com/js/deployJava.js"></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="http://java.com/js/deployJava.js"></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="http://java.com/js/deployJava.js"></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="http://java.com/js/deployJava.js"></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="http://dl.javafx.com/1.2/dtfx.js"></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

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.