Deploying Swing and JavaFX applications to the masses

Sun's (and now Oracle's) desires for Java/Swing's and JavaFX's success on the client depend upon how easy it is for the average user to install the appropriate version of Java/JavaFX on their platform. Furthermore, these desires depend upon browsers being able to launch Swing and JavaFX applications without problems.

To somewhat gauge a user's experience with installation and launch reliability, I recently used Sun's Deployment Toolkit to deploy several Swing applications to my website, and also deployed a JavaFX application as an applet via the JavaFX extension to this toolkit. I then used four browsers in a Windows XP (my only operating system) context to launch these applications.

This post discusses these deployment exercises, and presents my ease-of-installation and reliability findings for Mozilla Firefox 3.0.8, Internet Explorer 7.0.5730.11, Google Chrome 1.0.154.53, and Opera 9.62. It also reveals something strange about the JavaFX 1.1 compiler that I discovered shortly after working on the JavaFX application introduced later.

Swing application deployment

The first exercise deploys a Swing application that converts (via a Web service) between Roman numerals and integers. The application is the centerpiece of my Use SAAJ to Communicate with Web Services article, and is packaged in a RomanNumerals.jar file that consists of several classfiles and an empty manifest.

After configuring my Web server so that all files with the .jnlp file extension associate with the application/x-java-jnlp-file MIME type, I created a RomanNumerals.jnlp Java Network Launch Protocol (JNLP) file. Listing 1 reveals this file's contents.

Listing 1: RomanNumerals.jnlp

<?xml version="1.0" encoding="utf-8"?>
<!-- JNLP File for RomanNumerals -->

<jnlp codebase="http://javajeff.mb.ca/articles/usaajtcwws/" 
      href="RomanNumerals.jnlp">
  <information>
    <title>Roman Numerals</title>
    <vendor>Jeff Friesen</vendor>
    <description>Roman Numerals</description>
    <homepage href="http://javajeff.mb.ca"/>
    <offline-allowed/>
  </information>

  <resources>     
    <jar href="RomanNumerals.jar"/>   
  </resources>

  <application-desc main-class="RomanNumerals"/>
</jnlp>

You'll notice that I've omitted the spec="1.0+" attribute that is often present in a <jnlp> tag -- this attribute defaults to "1.0+", according to the JNLP spec. I've also omitted a j2se (or java) element from within the resources element, because I'm not relying on the auto-downloader to download a Java Runtime Environment (JRE).

After copying RomanNumerals.jar and RomanNumerals.jnlp to a suitable location on my website (http://javajeff.mb.ca/articles/usaajtcwws/), I created the script that's shown in Listing 2.

Listing 2: Script for deploying the Roman numerals application

<script type="text/javascript" src="http://java.com/js/deployJava.js">
</script>

<script type="text/javascript">
  var url = "http://javajeff.mb.ca/articles/usaajtcwws/RomanNumerals.jnlp";
  deployJava.createWebStartLaunchButton (url, '1.6.0');
  document.writeln (" (RomanNumerals)");
</script>

This script uses Sun's Java Deployment Toolkit (deployJava.js) and its createWebStartLaunchButton() function to output a launch button for the specified URL. When clicked, associated code ensures that at least the official release of JRE 6 is installed (installing the most recent JRE 6 if needed), and launches the application via JNLP/Java Web Start.

With JRE 6u13 already installed on my platform, I pointed each of my browsers to http://javajeff.mb.ca/cgi-bin/makepage.cgi?articles/usaajtcwws/usaajtcwws, and proceeded to launch this application by clicking the Launch button -- Figure 1 shows the launch in the context of Firefox. Unsurprisingly, I experienced no program crashes or otherwise strange behaviors.

Figure 1: The RomanNumerals application user interface features a gradient background. (Click to enlarge.)

To see what would happen with no JRE present, I uninstalled JRE 6u13 and clicked the Launch button for each browser. Firefox and Internet Explorer responded by presented the same sequence of dialog boxes for installing the JRE. Figure 2 reveals the initial Downloading Java dialog box.

Figure 2: The initial Downloading Java dialog box (shown here for Internet Explorer) appears when the Launch button is clicked. (Click to enlarge.)

This dialog box was succeeded by the following sequence of dialog boxes:

• Downloading Java Installer
• Java Setup - Welcome (click the Accept button)
• Java Setup - Yahoo! Toolbar (click the Next button)
• Java Setup - Progress
• Java Setup - Complete (click the Finish button)

After clicking Finish, the application started running with no problems.

Although some users might not appreciate having to navigate through several dialog boxes before the application starts to run (I wonder if there's a way to make this process more transparent, especially for users who know nothing about Java, and who don't want to know anything about this technology), the situation is worse for Chrome and Opera users.

With Chrome, I was taken to a page (see Figure 3 for an excerpt) where I was told to click a link to download the JRE executable. After clicking this link, responding to Chrome prompts, and responding to a sequence of dialogs similar to those shown earlier, I found that I had to close and restart Chrome, navigate back to the page, and click Launch to launch the application (which launched and ran without problems).

Figure 3: Click the link to download the JRE executable. (Click to enlarge.)

With Opera, I found myself confronted with a Downloading file RomanNumerals.jnlp dialog box presenting only an Other application... category for opening this JNLP file. Basically, I'm required to click this dialog box's Open button (see Figure 4) to associate my C:\Program Files\java\jre6\bin\javaws.exe file with the .jnlp file extension.

Figure 4: Clicking the Launch button leads to an unexpected result. (Click to enlarge.)

Because there was no JRE (and certainly no javaws.exe file) installed on my Windows platform, I couldn't automatically install the necessary JRE to launch the application. (For more information on Opera and Java Web Start, check out the Java Web Start : Java Glossary page from Canadian Mind Products.)

I'm not sure about market penetration for Chrome or Opera, but some users will probably prefer these browsers, and many of them (especially in Opera's case) probably won't bother (or have the savvy) to install Java. Perhaps Sun will work with Chrome and Opera vendors to improve their browsers' interaction with the Deployment Toolkit. Doing so can only help to expand the market for your Swing applications.

JavaFX application deployment

If you've visited the javafx.com website, you've probably encountered pages that embed JavaFX applications as applets. This website also provides helpful information on deploying these applications as applets or Java Web Start-launchable applications. Over the weekend, I used this information to deploy a JavaFX application as an applet on my website.

Specifically, I deployed the application, which presents a slideshow of various objects in the solar system, on my Deploying a JavaFX Application article page. Figure 5 reveals this application's applet running in the context of the Google Chrome browser.

Figure 5: Transitioning from the Sun to Mercury. (Click to enlarge.)

The slideshow application -- its article page introduces this application, along with the steps I took to deploy it -- also ran without problems in the context of the Firefox and Internet Explorer browsers. However, Opera didn't fail to disappoint. After telling Opera that it was okay to run the applet, this browser presented a blank applet area on the Web page, and Listing 3's console-based exception information.

Listing 3: Opera's Java console reveals various problems when attempting to launch the JavaFX applet

<pre>-- Opera - Java Console --

Java vendor: Sun Microsystems Inc.
Java version: 1.6.0_13

type 'h' for help

--
java.security.PrivilegedActionException: java.lang.ClassNotFoundException: java.lang
	at java.security.AccessController.doPrivileged(Native Method)
	at com.opera.PrivilegedThread.run(LiveConnectPrivilegedActions.java:290)
	at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.ClassNotFoundException: java.lang
	at com.opera.AppletClassLoader.findClass(AppletClassLoader.java:369)
	at java.lang.ClassLoader.loadClass(Unknown Source)
	at com.opera.AppletClassLoader.loadClass(AppletClassLoader.java:433)
	at java.lang.ClassLoader.loadClass(Unknown Source)
	at com.opera.PrivilegedFindClass.run(LiveConnectPrivilegedActions.java:266)
	... 3 more
Caused by: java.io.IOException: HTTP Connection failed.
	at com.opera.AppletClassLoader.readClassFile(AppletClassLoader.java:378)
	at com.opera.AppletClassLoader.access$100(AppletClassLoader.java:34)
	at com.opera.AppletClassLoader$4.run(AppletClassLoader.java:360)
	at java.security.AccessController.doPrivileged(Native Method)
	at com.opera.AppletClassLoader.findClass(AppletClassLoader.java:358)
	... 7 more
JNLPAppletLauncher: static initializer
Exception in thread "AWT-EventQueue-2" java.lang.ClassNotFoundException: slideshow.Main
	at com.opera.AppletClassLoader.findClass(AppletClassLoader.java:369)
	at java.lang.ClassLoader.loadClass(Unknown Source)
	at com.opera.AppletClassLoader.loadClass(AppletClassLoader.java:433)
	at java.lang.ClassLoader.loadClass(Unknown Source)
	at java.lang.ClassLoader.loadClassInternal(Unknown Source)
	at java.lang.Class.forName0(Native Method)
	at java.lang.Class.forName(Unknown Source)
	at com.sun.javafx.runtime.adapter.Applet.launchStage(Unknown Source)
	at com.sun.javafx.runtime.adapter.Applet$1.lambda(Unknown Source)
	at com.sun.javafx.runtime.adapter.Applet$1.invoke(Unknown Source)
	at com.sun.javafx.runtime.adapter.Applet$1.invoke(Unknown Source)
	at com.sun.javafx.runtime.Entry$2.run(Unknown Source)
	at java.awt.event.InvocationEvent.dispatch(Unknown Source)
	at java.awt.EventQueue.dispatchEvent(Unknown Source)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
	at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
	at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.awt.EventDispatchThread.run(Unknown Source)
Caused by: java.io.IOException: HTTP Connection failed.
	at com.opera.AppletClassLoader.readClassFile(AppletClassLoader.java:378)
	at com.opera.AppletClassLoader.access$100(AppletClassLoader.java:34)
	at com.opera.AppletClassLoader$4.run(AppletClassLoader.java:360)
	at java.security.AccessController.doPrivileged(Native Method)
	at com.opera.AppletClassLoader.findClass(AppletClassLoader.java:358)
	... 19 more

Once again, I decided to see what would happen when I tried to launch an application without JRE 6 installed on my platform. After removing the previously installed JRE 6u13, I surfed to this Web page, and was greeted by the blank applet window and "Java needed. Click for details." link that are shown in Figure 6.

Figure 6: Encountering the blank applet window and "Java needed..." link on Internet Explorer. (Click to enlarge.)

For each of Firefox, Internet Explorer, and Chrome (there's no point in trying Opera), clicking the link resulted in a dialog box presenting the message The current version of Java on this system (0 - unknown) does not support JavaFX. Install Java now? (This message appeared even though there was no Java on my system), along with OK and CANCEL buttons. I clicked OK.

In response, I discovered an identical experience to when I installed the JRE for the Swing application. After completing the install, I decided to try dragging the JavaFX applet onto the desktop. This task is possible for Firefox and Chrome, by pressing Alt and the left arrow keys, and then positioning the mouse cursor over the applet and dragging the mouse. Figure 7 demonstrates applet dragging in a Chrome context.

Figure 7: Click the small x (slightly above and to the right of the applet's window) to close the applet and cause it to reappear in the Web page. (Click to enlarge.)

After completing both exercises, I see improvement (from a user perspective) in getting Java onto the platform for the Firefox and Explorer browsers. However, Chrome and (definitely) Opera need work to improve this experience. Also, except for Opera exceptions, I experienced no program crashes or other anomalies while running the Swing application and JavaFX applet, but then I only tested under Windows XP.

A JavaFX compiler curiosity

My initial post to this blog pointed out an oddity in the JavaFX 1.0 and 1.1 compilers: It's possible to invoke functions that don't exist. I've recently discovered another peculiarity, specifically in the JavaFX 1.1 compiler (and probably in JavaFX 1.0 and 1.1.1 as well). The script in Listing 4 demonstrates this peculiarity.

Listing 4: A peculiar script

function foo1 (): Void
{
    println ("foo1() called");
    return 10.0
}

function foo2 (): Void
{
    println ("foo2() called");
    23
}

foo1 ();
foo2 ()

It shouldn't be possible to return a value from a function whose return type is Void, and yet the compiler allows this syntax. When you run the script under JavaFX 1.1, you'll notice foo1() called followed by foo2() called messages in the standard output. Fortunately, the compiler is smart enough to flag an error when you try to assign the function to a variable, as in var x = foo1 ();.

Conclusion

Because I could only deploy in a Windows XP context, I'm curious about your experiences when you try to install Java/JavaFX and run the Swing application and JavaFX implementation applet on your Linux, Mac OS X, Solaris, or Vista operating system. I'd also like to know about any JavaFX 1.1 compiler oddities that you've encountered.

Like this blog? Subscribe to the CSJ Explorer RSS feed