Using the Java Plug-in

Abstract

[write this]

Contents

APPLET

Suppose you have an applet whose main class is called "XYZApp.class", and the applet takes one parameter, "model", the path to a file for the applet to display. If your server directories are set up as follows in (Fig.1), then "XYZ.html" could contain the APPLET tag in (Listing.1). If someone visits the page with a browser that does not recognize the APPLET tag, they will see a message to that effect. If they use a browser that does recognize APPLET but has Java support disabled, they will a different message, defined in APPLET's ALT parameter. If Java support is activated, the applet should appear in their browser, at a size of 300x300 pixels, right-aligned on the page, as interpreted by the browser's default JVM.

In the HTML listings below, required attributes (such as "CODE") are uppercase, and optional ones (such as "alt") are lowercase.

Plug-in architecture

Suppose, in the above example, that the visitor is using Netscape Navigator 3.0. The Symantec[?] JVM used therein can only interpret applets compiled under JDK-1.1[?] or earlier. If XYZApp.class was compiled under JDK-1.1.7 or JDK-1.2, the JVM will be unable to run it, and the browser will report an error.

To solve the endemic problem of spotty and lagging browser support for the newest versions of the JDK, JavaSoft has released the "Java Plug-in" for Netscape and Microsoft browsers.

Netscape Communications introduced "plug-in" technology with Navigator 2.0[?], so that the browser could perform inline display of data it did not have inbuilt support for. (For instance, Navigator-2.0 knew how to render GIF and JPEG images, but not Macromedia Shockwave movies.) This replaced the older "helper program" system introduced with NCSA Mosaic, in which an unsupported file were handed off to an accessory that would display it in an external window. The rival MS Internet Explorer 3.0[?] inaugurated a similar but incompatible framework, utilizing Microsoft's "COM/ActiveX" architecture.

As originally instituted, when the user encountered unsupported content, he had to manually locate, download and install the appropriate plug-in. To automate this task, new HTML tags were introduced by the two vendors. These tags not only point to the content (as IMG and APPLET do), they also specify what plug-in is necessary to view it, and where it might be downloaded. The browser can then automatically retrieve and install the plug-in (subject to the user's approval).

Introduction to OBJECT and EMBED

Netscape uses the EMBED tag; MSIE the incompatible OBJECT tag. It is possible to write HTML code that will interpret the appropriate tag for whichever browser is interpreting it, but the result is long, messy, and technically illegal syntax. The hack relies on the fact that Netscape does not recognize the OBJECT tag, that MSIE ignores the EMBED and NOEMBED tags, and that only MSIE recognizes the COMMENT tag (and ignores any tags within it. This is distinct from the <!-- --> HTML comment tag). The "XYZApp" example from (Listing.1) is translated below in (Listing.2).

(Note how the COMMENT tag overlaps the EMBED/NOEMBED tag pair. This is the illegal HTML syntax that qualifies the solution as a hack.)

Details of OBJECT and EMBED

The "classid" attribute of the OBJECT tag is an immutable alphanumeric identifier for the particular ActiveX control referenced by the tag. The Java Plug-in version 1.1 has one such identifier; version 1.2 has a different one. If your tags all refer to the same version of the same ActiveX control, you never have to change that attribute. It has no equivalent in EMBED. [Actually, 1.1.1, 1.1.2, and 1.2 all use the *same* clsid. What *does* it denote?]

OBJECT/codebase and EMBED/pluginspage serve to specify the URL from which the ActiveX control (or plug-in) may be downloaded. The URLs in (Listing.2) are provided by JavaSoft, but you can mirror the downloads on your own server. This is handy if you wish to restrict traffic to within a corporate firewall.

Note that Microsoft has chosen to be confusing: the APPLET/codebase attribute (which specifies where the applet's code is located relative to the HTML page) transforms into PARAM/codebase when used with OBJECT, since OBJECT/codebase has a completely different function. It transforms into EMBED/java_codebase under Netscape.

All of the PARAM tags associated with APPLET are repeated with OBJECT. It also adds a new one: PARAM/type, which specifies the MIME type of the ActiveX control. EMBED absorbs all the PARAM tags (including PARAM/type) as attributes. Applet specific parameters are absorbed; e.g. PARAM/model becomes EMBED/model. OBJECT's PARAM/type becomes EMBED/type, serving the same purpose as in OBJECT.

OBJECT is a general tag that doesn't recognize the specific APPLET attributes; those attributes have to be exported to PARAM tags. Conversely, EMBED will accept an unlimited number of attributes, but it can't cooperate with the PARAM tags APPLET uses to send data to the applet, they have to be imported as extra attributes to EMBED. Since APPLET recognizes attributes like CODE, ARCHIVE and so forth but can't reserve them, name collisions are possible when translating from APPLET/PARAM to EMBED or OBJECT. Thus, there are five alternative names available (listed in (Table.1)), each prefixed with "java_".

The code and object attributes are mutually exclusive; the former points to a Java bytecode .class file containing the applet's main class, and the latter to a serialized object file. Attribute mayscript specifies (value=true|false) whether the applet may access netscape.javascript.JSObject for scripting purposes.

The following (Table.1) summarizes the equivalents between the APPLET, OBJECT, and EMBED tags.

The Java Plug-in

[Are there different versions of the JPI for each OS? Different versions for MSIE and Netscape? Can the EMBED/pluginspage attribute point at a file instead of a download page?] JPI available for Netscape Navigator on Win95/98/NT4.0 and Solaris. But not NT3.51!

Once installed, JavaSoft's Java Plug-in adds an item (the Plug-in Control Panel) to the Windows Start menu. The Panel takes a while to open [is it a Swing app itself?]. From it, you can choose to disable caching of applets. (If cached, even the standard browser "shift-reload" trick will fail to reload the applet.) If you have multiple JREs installed on your system (likely if you are a developer) you can select to use one of them, or the Plug-in's own JVM. (Changing the JRE may have unexpected effects in MSIE. Symptoms include pages with applets not loading, and failure to appear of hyperlinks' blue highlighting and underlining. Reverting the JRE setting may stem the anomalies.)

The ";version=1.x" part of each MIME type is optional. Use "application/x-java-applet" if the tag points to an applet, or "application/x-java-bean" if it points to a JavaBean. Codebase and pluginspage have to be absolute URLs.

There is a "Java Plug-in HTML Converter" which can read an webpage containing an APPLET tag and translate it to the EMBED/OBJECT pair. You can specify the location of the appropriate Plug-in download for each tag. While the HTML code produced works, it is extremely messy. I recommend cut-and-paste of the neatly formatted code in (Listing.2).

Making the Plug-in available on an intranet

The details above in (Table.2) primarily relate to downloading the Java Plug-in from its default URL at JavaSoft. If you wish to emplace it on your intranet so that employees' browsers need not go so far afield to retrieve it, the syntax is slightly different.

For MSIE and OBJECT, the URL should point, not to the .cab (Windows "cabinet" file), but to the .exe (self-installer) stored within it. The #Version=xxxx suffix is still necessary.

For Netscape and EMBED, you have to point to a download page that allows the user to manually choose between platforms. JavaSoft's Plug-in documentation claims to point to an example page, but is terse otherwise; and the indicated page is overcomplicated with license agreement guards that wouldn't apply in an intranet. (Presumably the corporation would agree as a whole.) The whole situation is even more confusing (for those of us trying to apply JavaSoft's instructions) because, starting with Plug-in-1.2[?], if you want to manually download the Plug-in (rather than let the browser do it for you the first time it encounters the tag), it's bundled with the JRE-1.2.

Further information