Java Plug-in

Simply put, Java is about embedding objects into applications. For an application to embed Java objects, there must be a Virtual Machine (VM) and a set of standard class libraries available to the application.

This simple idea has been bogged down in a morass of competing implementations from the major browser vendors who change Java VMs and adopt different versions of class libraries to fit their own evolving needs. The result has been a marketplace filled with a complex array of different runtime environments for different browsers and different platforms, all in different versions.

Getting the picture

Three years ago, the Web began to get tons of press. In response, Sun built Hot Java as an example of an application that could support embedded Java objects -- in this case, applets. Netscape joined in with its support of Java and the rest is history.

The only problem was that nobody had Java VMs loaded on their systems. The solution Netscape, and later Microsoft, chose was to hard-link the VM into the release of the browser. This decision has been the ultimate cause of many of the criticisms about Java not running the same everywhere. By hard-tying the VM to the browser, different browsers had different references of the state of the VM and libraries at the time of their release, causing differences in performance, bug fixes and available libraries. By embedding the VM in the browser, it was impossible to update the VM independently from the browser.

Since the original intention was for Java to be available to any application, not just the browser, the VM should ultimately be available as an operating system driver (as it already is in OS/2 Warp). Sun addressed this last year with the release of the Java Runtime Environment (JRE), which contains everything necessary to execute Java code (the VM and class libraries). Once JRE is loaded onto your system, any application can embed Java objects just like a browser. The problem is that the browsers were still using their own hard-coded versions of the VM and had no mechanism for accessing JRE.

Sun's Java Plug-in is a mechanism to access the JRE via the browser from HTML pages. It is freely available for download from Sun's Java site on the Web. The current release supports Java 1.1.5 (which includes a just-in-time compiler, signed applets, Java Beans, Remote Method Invocation, the Java Native Interface, Java Database Connectivity and the new Swing 1.0 components). Java Plug-in will automatically be installed on a user's machine using standard browser plug-in or installation methods. The user is automatically redirected to the Java Plug-in download page the first time it is encountered.

Java Plug-in is installed as a browser plug-in for Netscape Navigator 3.0/4.0 on both Windows 95, NT 4.0 and Solaris 2.5/2.6 platforms (Sun claims that it intends to support all Navigator platforms). For Internet Explorer 3.0/4.0 on Windows 95 and NT 4.0 platforms, it operates as an ActiveX control. The Windows installation for either Explorer or Navigator will automatically install it into the other, circumventing double-installation for those who use both browsers.

Getting up and running

Use of Java Plug-in over the default VM is triggered by the EMBED tag in Navigator or the OBJECT tag in Explorer. Both techniques involve specifying a MIME type to trigger the Java Plug-in plug-in or control. This is wonderful for dealing with Java versions. If your applet uses some great new feature of Java 1.1.6, you can guarantee the correct version of Java will be used by specifying the MIME type with the version you require. This will result in an updating of your version of Java Plug-in and JRE (only) if that version is not loaded on the user's machine.

MIME Type	Java ObjectType/Java Version
application/x-java-applet;	Applet / Java Plug-in with the current JRE
application/x-java-applet;version=1.1	Applet / Java Plug-in with Java 1.1
application/x-java-applet;version=1.2	Applet /Java Plug-in with Java 1.2
application/x-java-bean	Bean / Java Plug-in with the current JRE
application/x-java-bean;version=1.1	Bean / Java Plug-in with Java 1.1

There is a caveat in using Java Plug-in. You can forget the old familiar APPLET tag. Your HTML must contain plug-in and embedding directives. Unfortunately, the mechanism is different between Navigator and Explorer.

For example, to put applets on a page or to use the default VM that comes with your browser, even if Java Plug-in is installed, you traditionally use the APPLET tag:

But to use Java Plug-in with Netscape, you must use the EMBED tag:

Notice that you must specify the MIME type and the pluginspage so the browser will know where to download Java Plug-in the first time it encounters the Java Plug-in MIME type. The EMBED tag does not understand the PARAM subtag the APPLET tag uses. Applet parameters must be specified directly inside of the EMBED tag. Code, codebase, width, height and so forth are specified as they were in the APPLET tag.

To use Java Plug-in with Explorer, you must use the OBJECT tag:

Listing 1

The OBJECT tag for ActiveX controls in Explorer works differently than the APPLET tag. For OBJECT tags the codebase is the location of the ActiveX control required for the embedded object. As a result, the Java code, codebase and (MIME) type are specified using PARAM tags.

Requiring different mechanisms for using Java Plug-in between Navigator and Explorer does not mean we need to have different Web pages for each browser. Taking advantage of quirks in supported and unsupported tags between the two browsers, you can generate HTML that will use Java Plug-in in the respective browsers or the default VM if Java Plug-in can not be installed. It is hideous hack HTML code, but you don't have to generate it yourself, because Sun provides Java Plug-in with an HTML converter for transforming APPLET tags into the appropriate tags that will work with Navigator, Explorer or both.

Listing 2

Get it while it's hot

Swing is included in the 1.1 release, most applets and Beans using 1.2 should work in the initial release.

Java Plug-in is free, so now anyone can use this new mechanism to speed up the update schedules of bug fixes, performance enhancements and library functionality to the VM independently of the browser.