random memes }

Java Applets that "just work"

Summing up the results from prior post, getting Java Applets to "Just Work" in the browser boils down to a "to-do" list on the part of multiple parties.

  1. Sun must offer a consistent API for downloading the appropriate JRE for the user's machine. This API should look like...

    http://downloadserver.sun.com/downloads/jre to download the latest JRE. http://downloadserver.sun.com/downloads/jre?version=1.4 to download the latest 1.4 JRE. http://downloadserver.sun.com/downloads/jre?version=1.4.2 to download the latest 1.4.2 JRE. http://downloadserver.sun.com/downloads/jre?version=1.4.2_10 to download the latest 1.4.2_10 JRE.

    Note that in each case the server can use browser detection to supply the appropriate binary for the browser and operating system.

    Note also that the API **must never change** once offered. Also the default installation should be as silent as possible.

  2. Firefox must provide a means to specify the minimum or exact Java version required. Right now we will have a failure every time an earlier Java version is installed on the user's machine than is required by the applet. A better solution would be for Firefox to look for a version= (or similar) attribute on APPLET, EMBED, and OBJECT tags. If the installed Java version is earlier than specified, then offer to install the appropriate Java version. The default would be to download from the above Sun URL, and could be overridden using a pluginurl= attribute (or similar). Note that the interpretation of the version= attribute should follow a similar scheme.

    version=' ' or when unspecified accepts whatever Java version is installed on the machine, or offers to download the latest JRE. version='1.4' offers to download the latest 1.4 JRE if no or a non-1.4 version is installed on the machine. version='1.4+' offers to download the latest JRE if no or a version earlier than 1.4 is installed on the machine. version='1.4.2' offers to download the latest 1.4.2 JRE if no or a non-1.4.2 version is installed on the machine. version='1.4.2+' offers to download the latest JRE if no or a version earlier than 1.4.2 is installed on the machine. version='1.4.2_10' offers to download the latest 1.4.2_10 JRE if no or a non-1.4.2_10 version is installed on the machine. version='1.4.2_10+' offers to download the latest JRE if no or a version earlier than 1.4.2_10 is installed on the machine.

    Note the use of "+" to distinguish between the need for a specific version, or for anything later than a specific version.

    A possible work-around is to load a shim applet compiled against (say) Java 1.1, test the JRE version, then offer to install a later JRE. I am not sure if this is even possible. Certainly this may cause problems if in-page Javascript needs to communicate with the applet.

  3. The JSP tag jsp:plugin should do browser detection (in the default case). For IE (to avoid getting the Microsoft JVM) the jsp:plugin tag should emit an OBJECT tag of the form:

    The above assumes the Sun folks implement the suggested API. On all other platforms the jsp:plugin should emit an APPLET tag of the form:

    Note that the **version=** attribute is currently ignored.

For the moment, the best we can do for dynamically generated pages is check the sort of browser, and for IE emit the OBJECT tag (as below), and for everything else emit the APPLET tag (as below).

Yes, I know the HTML 4 standard deprecates the APPLET tag. Pragmatically - this is irrelevant. Browsers for compatibility will have to support the APPLET tag ... forever. Given the current (and future) state of affairs, we would all be better off restoring the APPLET tag to future HTML standards, with the addition above.

Yes, I know about the "trick" to wrap an EMBED inside an OBJECT that gets us one incantation the works in static HTML for both IE or Firefox. Given that EMBED is a Netscape-specific extension, there is no reason to expect this to work in other browsers. There is an even hairier incantation that uses in-page Javascript to conditionally emit either OBJECT, EMBED, or APPLET tags. Good luck verifying that this works in all environments. Better to use server-side dynamic HTML generation and keep the emitted HTML as simple as possible. The above approach of emitting an OBJECT tag for IE (to avoid the hoary Microsoft JVM), and an APPLET everywhere else is both simpler, and arguably safer.

Now - if I had unlimited free time (as if) - the right thing to do would be to ...

Right about now I can feel the appeal of accepting the Microsoft monoculture :).