Contrary to popular misconception, Java applets are a mature technology ideally suited for building highly interactive Web content. Although this hasn't always been the case, a lot has changed since Sun's introduction of Java over a decade ago. Previous articles in this series have discussed why the object tag alone can and should be used to deploy applets and how using the Javay deployment method can make life easier if you do. This article will address one of the most important questions of all when using applets: what happens if your user doesn't have Java?

Assume Your Users Won't Have Java

Java is ubiquitous, but it's not universal. Some users simply won't have a Java Virtual Machine (JVM) installed at all on their systems. Some will have one, but it will be disabled. Still others may have been browsing the Web for years, never realizing that Microsoft installed a hopelessly obsolete JVM on their machines without their knowledge, rendering useless a large amount of Web content.

Regardless of why they might not have the JVM your applet requires, assume that a good number of your users won't and plan accordingly.

But how?

The Javay Method and Deployment Failsafes

The Javay method for applet deployment can be broken down into three main parts:

1. Using the HTML 4 <object> tag - period. Neither <applet>, which is deprecated, nor <embed>, which isn't even part of HTML, are needed any longer.

2. Using Microsoft's conditional comments to create an opening object tag that will work with its browsers, but keeping it DRY by re-using the rest of the tag.

3. Suppressing the ridiculous "Click to activate" message in IE 6/7 with jActivating.

In contrast to other approaches, with the Javay method, we can:

• Know our applet will instantiate on all major browsers, and many niche browsers as well.

• Work only with standards-compliant HTML from start to finish.

• Stop using document.write to create tags, a method which unless properly trapped will silently fail without any indication of what's wrong when JavaScript is disabled or if the script fails for some other reason.

But perhaps the biggest advantages of the Javay method are the ones most often overlooked:

• It offers a cross-browser method to display failsafe content should Java be disabled or not installed.

• It provides a highly effective, cross-browser method for users to install Java directly from the page displaying the applet.

How the Failsafe Works

When modern browsers such as Firefox and Internet Explorer encounter an <object> tag requesting a plugin they don't understand, they do two very useful things:

1. They render any valid HTML appearing after the <object> tag's child <param> elements.

2. They prompt the user to install the correct plugin to view the content - without redirecting them to another page.

These two behaviors give us everything we need to gracefully fail if the Java plugin is unavailable. When the Java plugin is installed and enabled, users see the applet as planned. When the Java plugin is either not installed or disabled, users see both a placeholder of our choosing and a prompt, created by the browser itself, offering to install the missing plugin.

The <object> tag lets us take this even further. We can specify, down to the revision level, the exact version of Java needed to run an applet. If that requirement changes, all we need to do is change the <object> tag and users will be prompted to upgrade their JVM the next time they see our applet - if necessary.

Live Demo

Here's my company's 2D chemical structure editor, ChemWriter, deployed with the Javay method:

And here's what the failsafe code looks like when it's rendered:

One More Thing

We can take failsafes to yet another level, if we'd like. Let's say Joe comes to our site without the an installed Java plugin. Internet Explorer 6 informs him via a popup that Java is needed. Impatient to see the site's content, he closes the dialog. Without being redirected, Joe can see all of the site's content, except for the parts requiring Java, for which he sees a custom "Plugin Not Found" placeholder. Discovering that the site's content consists of highly-relevant information, he decides he wants to install the Java plugin after all. Clicking on placeholder image takes him to a Java installation page.

Unlike other Java installation pages Joe may have seen, this one is specific to his browser, Internet Explorer 6.

This approach work very well in practice. For example, my company's website, metamolecular.com uses it. Try visiting the default Java installation page, and if your browser is included below, you'll be redirected to the browser-specific Java installation page:

• Default Page

• Firefox Page

• Internet Explorer 6 Page

• Internet Explorer 7 Page

• Safari Page

More information can be found in this article on deploying ChemWriter.

Last Thoughts

Java applets gained a deserved reputation in the late '90s for being difficult to deploy, a view that's now worth reconsidering. Using some simple techniques, Web applications can fail gracefully if Java is unavailable and then take steps to quickly get users back on track.

Getting software reliably and securely installed on any client system is difficult, especially on the open Web. But the Java plugin and the Javay deployment method make it about as straightforward as it can possibly be.

It's time reconsider applets.

Image Credit: brrtha

Java applets are easy to deploy in a standards-compliant way across multiple browsers - you just need to know how. The previous article in this series gave some general pointers to better applet deployment, including the use of the <object> tag. This article will show how to make this deployment method even more concise with the Javay Method.

Keeping it DRY

The code from the previous article used two completely different <object> tags: one for Internet Explorer and one for all other browsers:

<!--[if !IE]> -->
<object classid="java:com/metamolecular/chemwriter/applet/EditorApplet.class" 
              type="application/x-java-applet"
              archive="/path/to/applets/chemwriter.jar" 
              height="350" width="550" >
  <param name="code" value="com/metamolecular/chemwriter/applet/EditorApplet.class" />
  <!-- For Konqueror -->
  <param name="archive" value="/path/to/applets/chemwriter.jar" />
  <param name="persistState" value="false" />
  <center>
    <img src="/path/to/images/chemwriter_logo.png" />
    <p><strong>ChemWriter content requires Java 1.4.2 or higher, which your browser does not appear to have.</strong></p>

    <p><a href="http://www.java.com/en/download/index.jsp">Get the latest Java Plug-in.</a></p>
  </center>
</object>
<!--<![endif]-->
<!--[if IE]>
<object classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93" 
                codebase="http://java.sun.com/products/plugin/autodl/jinstall-1_4-windows-i586.cab#Version=1,4,0,0"
                height="350" width="550" > 
  <param name="code" value="com/metamolecular/chemwriter/applet/EditorApplet.class" />
  <param name="archive" value="/path/to/applets/chemwriter.jar" />
  <param name="persistState" value="false" />
  <center>
    <img src="/path/to/images/chemwriter_logo.png" />
    <p><strong>ChemWriter content requires Java 1.4.2 or higher, which your browser does not appear to have.</strong></p>
    <p><a href="http://www.java.com/en/download/index.jsp">Get the latest Java Plug-in.</a></p>
  </center>
</object>
<![endif]-->

Conditional comments are used to ensure that IE sees one definition and standards-compliant browsers see another. But notice the large amount of repetition, specifically the parameters list, the failsafe code, and the closing <object> tag.

Surely there must be a better way.

A Widespread Problem

Microsoft's idiosyncratic use of the <object> tag doesn't just cause difficulties for Java applets: it rears its head with all plugin content. This problem is so widespread in the Flash world that its solution even has a name: Flash Satay.

In the language of Drew McLellan, inventor of Flash Satay, the applet code listing above is the "twice-cooked method" - we repeat the same code twice.

The twice-cooked method violates one of the most important principles in software development: Don't Repeat Yourself (DRY). It's an invitation cross-browser bugs. If we forget to include the same parameter twice, or if we mistakenly use one parameter for IE and another for standards-compliant browsers, for example, we've just created a potentially nasty headache for ourselves.

Drying Up the <object> Tag

We can DRY up our applet <object> tag by factoring out what's common: the parameters listing; the failsafe code; and the closing <object> tag:

<!--[if IE]><object classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93" codebase="http://java.sun.com/products/plugin/autodl/jinstall-1_4-windows-i586.cab#Version=1,4,0,0"
width="480" height="350"><script>/*<![endif]--><script type="text/javascript">/**/</script>
<!--[if !IE]><!-->
<object type="application/x-java-applet;version=1.4.2" width="480" height="350">
<!--<![endif]-->
  <param name="code" value="com/metamolecular/chemwriter/applet/EditorApplet.class">
  <param name="archive" value="/applets/chemwriter.jar">
  <param name="persistState" value="false">
  <param name="licenseKey" value="4BC4-3C59-3E7D-182B-92B7-2E68">
  <a href="http://metamolecular.com/java/">
    <img src="http://depth-first.com/demo/20080310/chemwriter_plugin.png" style="padding: 125.0px 190.0px 125.0px 190.0px; border: 1px dashed red;"/>
  </a>
</object>

This approach was inspired by the BlaTek Satay method, which uses the cute empty JavaScript as a way to prevent IE from showing unwanted characters. To my knowledge, it's never before been applied to applets.

In the long tradition of naming these hacks after the original Satay method, I call this one "Javay."

The Javay method's only repetition is in the width and height attributes. Even this redundancy could be eliminated, if we chose, by setting each to "100%" and enclosing the result in a <div> tag that did specify size.

The above code works in all major browsers, including Safari, Firefox, Internet Explorer 6 and 7, Opera, and Camino. If you find a browser on which the code doesn't work, I'd like to hear about it.

Here's what the code produces, using my company's 2D structure editor ChemWriter as an example:

Conclusions

To summarize, Java applets can be deployed in a cross-browser, standards-compliant way using the Javay Method. This method solves some of the trickier problems when deploying applets, specifically:

1. Uses the HTML 4 <object> tag, eliminating the deprecated <applet> tag.
2. Works on both IE and standards-compliant browsers in a DRY way.
3. Suppresses the annoying "Click to activate" message in IE 6 and 7 with jActivating.
4. Avoids the use of document.write and the problems that can arise if JavaScript is disabled.
5. When Java is either missing or not installed, provides a cross-browser failsafe (more on this next time).
6. Leaves us with nothing but pure, standards-compliant HTML to write, debug, and maintain.

We've pretty much got everything the old <applet> tag used to have - and more.

But what if your users don't have Java? Tune in next time to see how to solve this problem once and for all.

Image Credit: Things are Better with a Parrot