Auto-Install: Easier Launching of Java Web Start Applications

Print-friendly Version

Q: What's the difference between an application that's Java Web Start enabled and an application that's not?
A: One's deployable, the other's deplorable.

Developers writing Java applications for the Real World (the world outside cozy and manageable corporate networks), must deal with the "ubiquity of Java" problem. While the Java Runtime Environment (JRE) may be very prevalent on most machines in the world (some data puts the number close to 90% of the world's PCs), it is not yet on all machines. And when it is installed, it may use any of several Virtual Machines, from the latest release of Sun's VM to the original Microsoft JVM.

How is the developer supposed to widely deploy the application if they do not know which platform to target, or whether that platform will even be available? A developer may write the absolutely coolest, most productive and head-dizzyingly paradigm-shifting productivity application the world has ever seen, but if the intended audience cannot get the thing to run, what is the point?

The deployment group at Sun has been looking into this problem and coming up with solutions. In particular, there is one overriding problem that they are trying to solve: Launch a Java application from the browser under a specified version of the JRE.

This goal has several implicit problems that have to be resolved:

1. Detect whether the JRE exists on the system.
2. If it exists, determine its version.
3. If it does not exist on the system, or if the version differs from that required by the application, install the proper version.
4. After it is installed, launch the application.

It turns out that many of these problems have already been solved and are available in Tiger (Java SE), at least for specific browser and platform combinations. The existing solution involves an ActiveX plugin for Internet Explorer (IE) called Auto-Install. With a little JavaScript wrapper and this ActiveX plugin, all of these problems are solved and the application is off and running.

And with a little more simple JavaScript code, there is also an easier path to detection and installation for non-Windows/IE browsers and platforms.

Let's look at the different pieces that make this work.

1. Detect browser type
2. Internet Explorer on Windows
   1. Execute auto-install component (may require accepting installation by user)
   2. Auto-install does the following:
      1. Detects JRE and the version specified
      2. Installs JRE of the required version if necessary
      3. Launches specified application
3. Other Browsers
   1. JavaScript detection of JRE existence and version
   2. If appropriate JRE version unavailable, open new window to download site
   3. Spin in loop awaiting install
   4. Launch application once install is complete

Figure 1: Auto-Installer

As noted above, the easiest solution that exists today depends on the ActiveX technology of IE. So the first step should be to detect the current browser and platform, with some simple JavaScript code:

var detect = navigator.userAgent.toLowerCase();
var windowsIE = (checkPlatform("msie") && checkPlatform("win"));
function checkPlatform(string)
{
    place = detect.indexOf(string) + 1;
    thestring = string;
    return place;
}

If this code detects IE browser on Windows, then the auto-installer technology can be used quite easily. Using it entails simply pointing to the appropriate version of the auto-installer from the java.sun.com download site and passing in parameters that tell it what application to launch when it is ready. The ActiveX component will do the rest.

if (windowsIE) {
    document.write("<OBJECT
        codeBase=http://java.sun.com/update/1.5.0/jinstall-1_5_0_05-windows-i586.cab
        classid=clsid:5852F5ED-8BF4-11D4-A245-0080C6F74284 height=0 width=0>");
    document.write("<PARAM name=app
        VALUE=http://java.sun.com/products/javawebstart/apps/notepad.jnlp>");
	document.write("<PARAM NAME=back VALUE=false>");
	document.write("</OBJECT>");
 }

Some explanation of the above tags might help here:

• OBJECT: This is the tag that tells the browser to install and execute the auto-installer ActiveX component.
• CODEBASE: If the Java Web Start CLSID is not found on the system, the JRE version pointed to by this URL will be downloaded and installed.
• CLASSID: This is the Java Web Start CLSID for the Java Web Start Active-X control. This CLSID exists on a Windows system if Java Web Start 1.2 or greater is installed.
• HEIGHT/WIDTH: This OBJECT does not need to be visible in the browser; it exists simply to execute the auto-installer.
• PARAM NAME=app: Once the Java Web Start Active-X control is installed, it will invoke Java Web Start to launch the application specified by this URL (Notepad, in the case of this demo).
• PARAM NAME=back : This controls the behavior of the browser after launching the application; it can remain on the URL pointed to by the app URL or it can navigate back to the previous page.

On some versions of IE, especially those in XP ServicePack 2 and later, the user will be notified that an ActiveX component wishes to be installed and executed. This means the user will have to go through a manual process of accepting this installation before the auto-installer can proceed. Some developers may wish to put helpful text and images on the page to help guide users through this process as appropriate.

The OBJECT tag detects if the machine has Java Web Start 1.2 or above installed. If it does, Java Web Start launches and handles the rest of the process (if the JNLP file specifically requests another JRE that is not available on the user's machine, Java Web Start will perform the JRE-autodownload and install). If Java Web Start 1.2 is not available, an install of the latest version of the JRE is needed before the JNLP application is launched; this install and launching is handled by the auto-installer.

Once the auto-installer is installed, it executes automatically, detects whether a JRE exists, detects whether the right version exists, and starts an installation if necessary. Once the right version is installed, the auto-installer will finally launch the given application.

Observant readers will have noticed that this approach forces an install of one piece of software (auto-installer) in order to detect and install the JRE. Isn't this a tad redundant? Well, yes ... and no. Yes, this process essentially does two separate installs to get the single Java platform the user needs. But the auto-installer piece is quite small and lightweight, and it is quickly downloaded and installed. The auto-installer can then ensure that the user has the right JRE version family installed. Forcing the user through a full install of the appropriate version is a much more heavyweight means of accomplishing the end goal. Also, simply installing the JRE will not automatically launch the application when Java is there; the auto-installer takes care of this piece as well. So apart from the initial step of the user accepting the installation of this ActiveX plugin into the browser, the auto-installer is a much simpler mechanism to get what users need; the application launched using the appropriate version of the JRE.

If the JavaScript code detects that the user is not running Internet Explorer, the simple mechanism of the auto-installer is not applicable. What now?

In one sense, this is potentially a better situation; there are mechanisms in Mozilla-based browsers that can do some basic Java existence and version detection. These mechanisms may be used to determine that a JRE is already on the platform and does not need to be installed, and the application can simply be launched:

if (navigator.mimeTypes && navigator.mimeTypes.length) {
	webstartAvailable = navigator.mimeTypes['application/x-java-jnlp-file'];
}

In this example, there is a check of the navigator.mimeTypes field to make sure that this field holds something sensible on this browser (which should be the case in Mozilla-based browsers). There is then a check performed on whether Java Web Start is a known mimeType, which will be the case if a version of the JRE is installed that has Java Web Start (which is the case as of Java version 1.2). If Java Web Start is available, the application can be run directly if there is no version-dependency requirement, or some further version checking can be performed to ensure that there is some minimal version available. For example, there could be a check on whether 1.5 is installed by checking navigator mime types against "application/x-java-applet;version=1.5". The Web Start check above could become a function call instead, which can then perform a further check on version dependency at the same time:

if (!webstartVersionCheck("1.5")) {
    // launch the application
}

function webstartVersionCheck(versionString) {
    // Mozilla may not recognize new plugins without this refresh
    navigator.plugins.refresh(true);
    // First, determine if Web Start is available
    if (navigator.mimeTypes['application/x-java-jnlp-file']) {
        // Next, check for appropriate version family
        for (var i = 0; i < navigator.mimeTypes.length; ++i) {
            pluginType = navigator.mimeTypes[i].type;
            if (pluginType == "application/x-java-applet;version=" + versionString) {
                return true;
            }
         }
     }
 }

Note that a similar check could be run against version 1.4.2 with the string "1.4.2", likewise for other Java versions. Note also that version detection is limited to major (e.g., 1.5) or minor (1.4.2) versions; there is no mechanism for detection of specific update releases.

If these means fail and the user either does not have a JRE installed or lacks the appropriate version, it is time to point the user at the download site of java.com and ask them to perform a manual install. This process can be made easier for the user by opening up a new window directed to the download site, and the user can take it from there:

if (!webstartVersionCheck("1.5")) {
    window.open("http://jdl.sun.com/webapps/getjava/BrowserRedirect?locale=en&host=java.com",
        "needdownload");
}

Meanwhile, some more JavaScript code can make the user's life a little easier by continuing to spin and detect whether the JRE is installed yet:

launchTID =
    setInterval('launchJNLP("http://java.sun.com/products/javawebstart/apps/notepad.jnlp")',
	    100);

function launchJNLP(app) {
    if (webstartVersionCheck("1.5")) {
        clearInterval(launchTID);
        window.location = app;
    }
}

The above code will continually call the launchJNLP function every 100 milliseconds until the launchTID interval is cleared, which will only happen once the webstartVersionCheck() call succeeds. Essentially, the code will keep checking whether Java Web Start is available until it actually is available, after which it will launch the application. The reason to do this is that the end-goal is still launching the application for the user; installing Java is just an intermediate step, and this bit of code makes sure that goal happens. So if the JavaScript code can detect when the Java install process has finished, it can then launch the application automatically. A more robust approach would probably have a less-than-infinite loop, in case the installation does not happen for some reason; the script should finish eventually and give the user more information about what is preventing the application from running, perhaps including a link to the install site or a GetJava logo.

Once the webstartVersionCheck() succeeds, the script will launch the application by simply redirecting the browser URL to the JNLP file:

window.location = app;

There are many other detection mechanisms not covered in this article. For example, the IE browser can execute VBScript to detect Java plugin existence (although there are issues with this that may make it more involved than the auto-installer approach above). Applet technology can also be used to detect Java plugin existence and version information; one approach spawns a 1.0-compatible applet to detect the VM version; that information can then be used to spawn another applet of the appropriate version, or to optionally run portions of an applet that take advantage of newer Java features.

The mechanisms above are not flawless; the user can always choose to not install something, or they can close a browser window before the application launches, or they can leave the download page and go somewhere else instead of installing, or other unforseen events can occur. But even so, approaches like those above can make life much easier for both users and developers and make launching Java application much more likely than the more typical approach of simply providing a link to the download site and hoping the user takes the hint. More clever usage of Java detection can lead to more and better Java platform installations overall and better support for launching Java-based applications from the browser.

For a complete version of the JavaScript code that uses the approach above, check out this demo.

JDK 1.5 Deployment Documentation: More information on the auto-installer, and on browser, platform, and JRE detection.

GetJava Logo Program: Use logos and links that send users to the appropriate download site.