Plug into Java with Java Plug-in

Learn how Sun's software tool solves the lag time between Java releases and new browser versions

As Java technology matures, Sun Microsystems (Java's creator) releases new versions of Java via the Java Development Kit (JDK). Netscape and other browser vendors support each new version by adding that version's runtime component -- the Java Runtime Environment (JRE) -- to the next iteration of their browsers. However, the lag time between Sun's introduction of a new Java version and the release of browsers that support it has frustrated corporate intranet developers who need to make use of the latest JRE's features (and bug fixes). And Microsoft's refusal to completely support the JRE in Internet Explorer 4.0 and 5.0 has made the situation even more frustrating for developers.

Sun has a solution to these problems. This solution bypasses the vendor and relies on plug-in technology to distribute newer JREs.

A plug-in architecture -- essentially the combination of an architecture and plug-ins -- is a specification for and implementation of that part of a browser that dynamically loads plug-ins as needed. Both Netscape and Microsoft have added this architecture to their browsers. (The actual implementations of the architecture are quite different: Netscape uses a simple executable implementation, while Microsoft uses its ActiveX object model implementation.)

A plug-in is executable code that is stored in a library file. When referenced via special HTML tags, the browser loads this library, via its plug-in architecture, and starts running the library's code. (If you've ever come across a Web page that references Macromedia's Shockwave or the VXtreme Web Theater, you've seen examples of plug-ins at work.)

Sun's solution is the creation of a plug-in for Java, known as Java Plug-in.

What is Java Plug-in?

Java Plug-in is a software product that serves as a bridge between a browser and an external JRE. A developer "tells" the browser to use this external JRE by placing special HTML tags on a Web page. Once this is done, a browser can run Java applets or JavaBeans components that have access to all the features (within the limits of Java's security model) of this external JRE.

Sun released Java Plug-in 1.1 in April '98. Shortly thereafter, JavaWorld polled its readership to gauge reaction to this product. The Java Plug-in 1.1.1 and 1.1.2 maintenance releases followed. (See Resources for details on the JavaWorld poll and releases of Java Plug-in.)

Concomitant with the release of JDK 1.2 (now known as the Java 2 platform), Sun has released Java Plug-in 1.2. However, unlike previous releases, this release is currently only available for the Microsoft Windows (95/98/NT) platform. Sun is currently working to make Java Plug-in 1.2 available for its Solaris platform.

This article explores Java Plug-in 1.2, starting with a discussion on how to download and install this technology. It is based on my experience using Java Plug-in 1.2 with the Internet Explorer 3.02 and Netscape Communicator 4.5 browsers, under the Windows 95 operating system.

Get plugged in!

Java Plug-in 1.2 is currently packaged with JRE 1.2. If you want to preinstall Java Plug-in, download and install JRE 1.2 from Sun's Web site, which is linked to in the Resources section. Or, you can choose to have your browser download Java Plug-in (with minimal intervention from you, depending on your browser) when you "surf" to a Web page that references that plug-in. Here's how:

When a browser comes across a Web page that requires the use of Java Plug-in, it checks to see if Java Plug-in has been installed on the same machine as the browser. If it hasn't, the browser must download and install the required files. The way this works depends on your browser, so we'll look at these differences next.

Netscape Communicator 4.5

If you're using Netscape Communicator, a Web page containing the HTML <EMBED> tag that references Java Plug-in will activate the download. We'll explore <EMBED> later in this article. For now, it's sufficient to know that <EMBED> contains information telling the browser what plug-in is required and where to get it. Figure 1 shows the initial download page that is displayed when Communicator encounters a Web page that references a noninstalled plug-in.

Figure 1. Communicator's plug-in download page

If you click on the image on that page, Communicator displays a "Plug-in Not Loaded" dialog box like the one shown in Figure 2.

Figure 2. Communicator's 'Plug-in Not Loaded' dialog box

This dialog box shows us that the browser knows exactly what it needs (a plug-in for application/x-java-applet;version=1.2) and where to get it (

So what happens when you click the "Get the Plug-in" button? The browser switches from the current page to the page specified by the Internet address in the dialog box. From that page, you follow directions to download and install JRE 1.2 with Java Plug-in.

Once the JRE with Java Plug-in has been installed, on Netscape's next encounter with a Web page that requires Java Plug-in, this plug-in will be loaded from the local machine's hard drive and the applet or JavaBeans component will run, as shown in Figure 3.

Figure 3. Running the applet

Internet Explorer 3.02

If you're using Internet Explorer, a Web page containing the <OBJECT> tag that references Java Plug-in will activate the process for downloading this plug-in. (As with <EMBED>, we'll explore the <OBJECT> tag later on in this article). This tag contains information that lets the browser know what kind of plug-in is required and where to get it. As we'll see, the process for getting Java Plug-in is somewhat more automated under Explorer than it is under Communicator. Figure 4 shows the initial page displayed when Explorer encounters a Web page that references a noninstalled plug-in.

(Note: The colorful diamond in the upper-left corner of the plug-in space appears if the computer is connected to the Internet. If the computer is not connected to the Internet, this diamond is replaced with a red X character, and obviously Explorer will do nothing to obtain the plug-in).

Figure 4. Explorer's plug-in download page

Assuming that the computer is connected to the Internet, Explorer proceeds to download a small ActiveX control that is responsible for downloading the Java Plug-in ActiveX control and JRE. Explorer displays the Verisign certificate associated with this first ActiveX control, as shown in Figure 5.

Figure 5. Verisign certificate

Assuming that you choose to install and run Java Plug-in, by clicking the Yes button in the previous dialog box, Explorer prompts you for locale information via the dialog box shown in Figure 6.

Figure 6. Explorer's locale dialog box

Once the locale information has been obtained (and you've clicked the Install button), Explorer displays a downloading dialog box, as shown in Figure 7.

Figure 7. Explorer's 'Downloading ...' dialog box

Once the download is complete, Explorer will attempt to start the JRE with Java Plug-in install program. (The first time I downloaded Java Plug-in through Explorer, I received a CAB -- Windows cabinet -- file-corrupt error message, which prevented the install program from starting and completing the installation. The install program started and completed successfully on the second attempt.) As soon as the install program finishes, Explorer loads and runs the applet (or JavaBeans component), as shown in Figure 8.

Figure 8. The resulting applet

Windows Registry settings

The JRE with Java Plug-in installation program records various JRE and Java Plug-in settings in the Windows Registry -- a centralized database of installation and other configuration data and a fundamental part of the various 32-bit Windows operating systems. The following table shows several Java Plug-in settings that are stored in this database. Each setting consists of a key that identifies a setting as well as the value of that setting.

HKEY_LOCAL_MACHINE/SOFTWARE/JavaSoft/Java Plug-in/1.2/JavaHome c:\Program Files\JavaSoft\JRE\1.2
HKEY_LOCAL_MACHINE/SOFTWARE/JavaSoft/Java Plug-in/1.2/RuntimeLib c:\Program Files\JavaSoft\JRE\1.2\bin\classic\jvm.dll
HKEY_CURRENT_USER/Software/JavaSoft/Java Plug-in/Debug Mode 0
HKEY_CURRENT_USER/Software/JavaSoft/Java Plug-in/Debug Port 2502
HKEY_CURRENT_USER/Software/JavaSoft/Java Plug-in/Java Runtime Default
HKEY_CURRENT_USER/Software/JavaSoft/Java Plug-in/Java Runtime Version 1.2
HKEY_CURRENT_USER/Software/JavaSoft/Java Plug-in/JIT Enabled 1
HKEY_CURRENT_USER/Software/JavaSoft/Java Plug-in/JIT Path symcjit
Table 1. Java Plug-in settings that are stored in the Windows Registry

The first two Java Plug-in settings are identified by the JavaHome and RuntimeLib keys. The values associated with these keys are used by Communicator and Explorer to locate the JRE home directory and the JRE's runtime virtual machine, respectively. The directory information contained in these values reflects the default installation directory selected during installation. The remaining keys are used by the Java Plug-in Control Panel.

Command and control

The Java Plug-in Control Panel is a Swing application that makes it possible to modify the behavior of Java Plug-in. The JRE/Java Plug-in installation program adds an entry to the Windows program launcher that, when selected, activates the Java Plug-in Control Panel. This entry consists of the following line (assuming the default installation directory):

"c:\Program Files\JavaSoft\JRE\1.2\bin\javaw.exe" -classpath ..\lib\rt.jar;
..\lib\jaws.jar sun.plugin.panel.ControlPanel

The control panel consists of a tabbed interface with three tabs (Basic, Advanced, and Proxies) and two buttons (Apply and Reset). The Basic tab controls the basic operation of Java Plug-in. For example, you can choose whether or not Java Plug-in's own Java console will be displayed. The Advanced tab controls which JRE will be used with Java Plug-in along with debugging. The Proxies tab controls the addresses and port numbers that Java Plug-in uses when communicating, via an intermediate computer, with another computer over the Internet. The Apply button saves any changes made in the control panel, while the Reset button restores default values.

Figure 9 shows the control panel with the Basic tab as the active tab.

Figure 9. Java Plug-in Control Panel -- Basic tab

The Enable Java Plug-in checkbox, when checked, enables Java Plug-in to run applets or JavaBeans components. The default setting is enabled (the box is checked).

The Show Java Console checkbox makes it possible to display the new Java console while running applets or JavaBeans components. As we'll see later, the console displays messages that have been printed by System.out and System.err objects (useful for debugging). The default setting is used to show the new Java console (the box is checked).

The Cache JARs in Memory checkbox, when checked, causes previously loaded applet or component classes to be cached and reused when that applet is reloaded, allowing for more efficient memory use. This option should be left unchecked if an applet or component is being debugged or if you want to make sure that the latest applet or component classes are being downloaded. The default setting is to cache JARs in memory (the box is checked).

The Network Access dropdown listbox allows you to choose which network access allowance you want to grant to your running applets and components. This option is enabled if you're running Java Plug-in 1.1.x. For Java Plug-in 1.2, you must use the new security architecture to enable the same behavior. (For more information, check out "Security and Signed Applets / Security Architecture" in the JDK 1.2 documentation.) By default, applets and components can only connect back to their original server (Network Access = Applet Host). When Network Access is enabled, you can use the following allowances, in addition to the default:

  • Disallow any network access so that an applet or component cannot make any network calls

  • Allow unrestricted network access (which is a security hazard and must be used very carefully) so that an applet or component can connect to any host server

The Java Run Time Parameters text field overrides the Java Plug-in default startup parameters by specifying custom options. You would use the same syntax for this text field that you use when specifying parameters to the java.exe command-line tool.

Figure 10 shows the control panel with the Advanced tab as the active tab.

Figure 10. Java Plug-in Control Panel -- Advanced tab

The Java Run Time Environment dropdown listbox allows Java Plug-in to run with JDK 1.2 or any JRE that's installed on your machine. Java Plug-in 1.2 is delivered with a default JRE (currently JRE 1.2). However, you can override this default JRE and use an older or newer version. The control panel automatically detects all versions of the JDK or JRE that have been installed on the machine. It displays these versions within the listbox. The first item in the list will always be Java Plug-in Default, while the last item will always be Other. If you choose Other, you must specify the path to the JRE or JDK 1.2.

The Enable JIT Compiler checkbox (Win32 platforms only) enables the just-in-time (JIT) compiler. If you enable the compiler, you must also specify the path to the JIT compiler. The JIT compiler must be located in the bin directory for the JRE or JDK that's been selected for the runtime environment.

The Enable Debug checkbox (in Internet Explorer only) enables the debugging environment only if you are using Explorer and you have the JDK installed. Check this box to enable debugging and specify the debug port. When the debugger is run inside Explorer, a window will pop up with the debugger password.

Figure 11 shows the control panel with the Proxies tab as the active tab.

Figure 11. Java Plug-in Control Panel -- Proxies tab

For those not familiar with the term, a proxy is a machine that sits between the Internet and an intranet and is there for security reasons. The idea is to make it impossible for an outsider to access the intranet (without knowing password details) while making it possible for intranet users to access the Internet.

The Use Browser Settings checkbox, when checked, makes use of the browser's proxy settings. If you uncheck this box, you can specify proxy addresses and ports for the HTTP, FTP, Gopher, secure sockets, and SOCKs protocols.

The Same Proxy Server for All Protocols checkbox, when checked, specifies that you only need to enter the proxy settings for one protocol, and these settings will be used for all protocols on the Proxies tab.

A tale of two consoles

If you've used any of Netscape's browsers, you've probably come across the Java console. The Java console, as mentioned above, is a special window that makes it possible to view applet messages (sent to either the System.out or System.err objects) and error messages, perform debugging tasks, and obtain applet state information. Figure 12 shows Communicator's internal Java console.

Figure 12. Communicator's internal Java console

However, Java Plug-in comes with its own Java console. This console is used by both Communicator and Explorer. Figure 13 shows the new console.

Figure 13. Java Plug-in's Java console

This console is used to display applet and error messages. Apparently, there are no commands for obtaining applet state information (unless I've missed something).

To <EMBED> or not to <EMBED>, that is the question

Earlier, I briefly mentioned the <EMBED> tag. Now it's time to explore this tag. Take a look at Figure 14, which shows the contents of NCdemo.html, an HTML file whose <EMBED> tag is used by Communicator to obtain Java Plug-in and run the specified applet.

  <EMBED code="demo.class" 
         message="Hello World!  This is Java Plug-in!">
Figure 14. NCdemo.html

The <EMBED> tag contains a list of attributes that are used by Java Plug-in. The code, codebase, height, and width attributes are identical to those same-named attributes that are found in the <APPLET> tag. (The codebase attribute isn't required in this example, but I've included it for illustrative purposes.) The pluginspage attribute is used in the event that Java Plug-in has not been installed on a user's machine. If the browser encounters a Web page with an <EMBED> tag that references Java Plug-in, and Java Plug-in has not been installed, the browser will obtain the plug-in from the page whose Internet address is specified by the pluginspage attribute. The type attribute informs Java Plug-in as to the type of executable that it will be dealing with: an applet or a JavaBeans component. These attributes are known as standard attributes.

Traditional <APPLET> tags can contain <PARAM> tags that allow an applet developer to specify parameters for modifying an applet's behavior. The <EMBED> tag does not support the <PARAM> tag. Instead, it treats parameters as attributes. For example, take a look at the message attribute in Figure 14. This attribute is not a standard attribute because I invented it for use with this applet. Instead, it is known as a parameter attribute. If used in conjunction with the <APPLET> tag, message would need to be encoded using the <PARAM> tag, as follows:

<param name="message" value="Hello World! This is Java Plug-in!">

It's possible to create an <APPLET> tag with one or more <PARAM> tags and assign a standard attribute name (such as code or type) as the name of a parameter. For example, in Figure 14, suppose we rename message to code. This results in the following line:

code="Hello World! This is Java Plug-in!">

But now we have a problem. After changing message to code, the <EMBED> tag ends up with two attributes called code. Which code attribute does Java Plug-in use to identify the starting applet or component class file? Fortunately, there is a solution.

Sun has created a set of alias attribute names that should be used when there is a name clash. In the previous case, where we have two code attributes, we would use code as the parameter attribute name. We would use an alias name to identify the class file. Table 2 provides a list of aliases.

Original attribute namesAlias attribute names
archive java_archive
code java_code
codebase java_codebase
object java_object
type java_type

Table 2. Original attribute names and aliases

When scanning the <EMBED> tag, if both the original and alias attribute name appear, Java Plug-in will treat the alias attribute as a standard attribute and the original attribute as a parameter attribute. For example, if code and java_code appear in the same <EMBED> tag, java_code will be treated as a standard attribute while code will be treated as a parameter attribute.

To conclude this section, Table 3 lists <EMBED> tag standard attributes.

Attribute nameDescription
archive This optional attribute specifies the name of a JAR archive.
code This required attribute (unless object is used) specifies the name of an applet or component. It cannot be used with the object attribute within the same <EMBED> tag.
codebase This optional attribute specifies the directory where an applet's/component's class and/or JAR files can be found.
height This required attribute specifies the applet's/component's window height.
mayscript This optional attribute specifies whether the applet/component is allowed to access netscape.javascript.JSObject. The value can be either true or false.
object This required attribute (unless code is used) specifies the name of a serialized applet or component. It cannot be used with the code attribute within the same <EMBED> tag.
pluginspage This attribute specifies the Internet address of a Web page where the plug-in can be downloaded.
type This required attribute identifies the type of executable. If it is an applet, the value should be application/x-java-applet;version=1.2 or application/x-java-applet. If it is a JavaBeans component, the value should be application/x-java-bean;version=1.2 or application/x-java-bean.
width This required attribute specifies the applet's/component's window width.

Table 3. <EMBED> tag standard attributes


Microsoft is in the habit of doing things its own way. For example, where Netscape uses the <EMBED> tag to access a plug-in as a simple executable, Microsoft uses the <OBJECT> tag to access a plug-in as an ActiveX object.

Figure 15 shows the contents of IEdemo.html, an HTML file whose <OBJECT> tag is used by Explorer to obtain Java Plug-in and run the specified applet.

<HTML> <HEAD> <TITLE>IEdemo</TITLE> </HEAD> <BODY> <OBJECT classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93" height="100" width="200" codebase=",2,0,0"> <PARAM NAME="code" VALUE="demo.class"> <PARAM NAME="codebase" VALUE="."> <PARAM NAME="type" VALUE="application/x-java-applet;version=1.2"> <PARAM NAME="message" VALUE="Hello World! This is Java Plug-in!"> </OBJECT> </BODY> </HTML>

Figure 15. IEdemo.html (the codebase URL has been split for readability; you'll want it to be one continuous string)

Like the <EMBED> tag, the <OBJECT> tag can contain a list of attributes. Unlike <EMBED> (but like <APPLET>), <OBJECT> supports <PARAM> tags.

Microsoft identifies ActiveX objects by using special 16-byte numbers that are known as globally unique identifers (GUIDs). Theoretically, every GUID that has ever been generated (and will ever be generated) is guaranteed to be unique (because a GUID contains a timestamp and a unique machine identifer -- like a network card address).

The classid attribute must contain the Java Plug-in ActiveX object GUID: 8AD9C840-044E-11D1-B3E9-00805F499D93. Interestingly, if you look in the Windows Registry, you'll come across the following key:


The default value of this key is JavaBeansBridge.Object, and this is what this ActiveX object really is -- a bridge between Explorer's ActiveX architecture and the JRE.

The height and width attributes define the dimensions of the applet's or component's viewable real estate.

The codebase attribute is not used in the same fashion as is its counterpart in the <APPLET> tag. This codebase identifies the location from which to download Java Plug-in when it's not found on the local machine.

The first three <PARAM> tags identify the main Java class file, the codebase for this class file, and the type of executable (applet in this case) via the code, codebase, and type attribute names, respectively.

Finally, the message attribute identifies an applet-specific parameter.

To conclude this section, Table 4 lists <OBJECT> tag attributes and parameters.

Attribute/parameter nameDescription
classid (attribute)This required attribute identifies the Java Plug-in ActiveX control. The value must be: 8AD9C840-044E-11D1-B3E9-00805F499D93
codebase (attribute)This required attribute should be a full URL pointing to a CAB file somewhere on the network. It should, by default, point to a page on Sun's Java Software Division Web site.
height (attribute)This required attribute specifies the applet's/component's window height.
width (attribute)This required attribute specifies the applet's/component's window width.
archive (parameter)This optional parameter specifies the name of a JAR archive.
code (parameter)This required parameter (unless object is used) specifies the name of an applet or component. It cannot be used with the object parameter within the same <OBJECT> tag.
codebase (parameter)This optional parameter specifies the directory in which an applet's class and/or JAR files can be found.
mayscript (parameter)This optional parameter specifies whether the applet/component is allowed to access netscape.javascript.JSObject. The value can be either true or false.
object (parameter)This required parameter (unless code is used) specifies the name of a serialized applet or component. It cannot be used with the code parameter within the same <OBJECT> tag.
type (parameter)This required parameter identifies the executable type. If it is an applet, the value should be application/x-java-applet;version=1.2 or application/x-java-applet. If it is a JavaBeans component, the value should be application/x-java-bean;version=1.2 or application/x-java-bean.

Table 4. <OBJECT> tag attributes and parameters

Pièce de résistance

Figures 3 and 8 showed the results of running an applet via Java Plug-in. Figures 14 and 15 showed the HTML tags that are used to activate Java Plug-in and run this applet. Before concluding, let's take a quick look at the applet. Figure 16 shows the applet's source code, in a file called

import java.awt.*;
import javax.swing.*;
public class demo extends JApplet 
   String message = "Sample message";
    public void init ()
        String dummy = getParameter ("message");
        if (dummy != null)
            message = dummy;
        JLabel label = new JLabel (message);
        label.setHorizontalAlignment (JLabel.CENTER);
        label.setBorder (BorderFactory.createLineBorder (;
        getContentPane ().add (label);

The applet shown in Figure 16, above, is known as a Swing applet. Instead of simply being an extension of the Applet class, Swing applets are extensions of the JApplet subclass. The init () method makes a call to the getParameter(String) method to obtain the value of the message parameter. This message is assigned to a JLabel component and then center-justified. Finally, this component is given a black-lined border and added to the applet's content pane (a container object).


This article has provided an introduction to Java Plug-in. As we have seen, this technology makes it possible for the Netscape Communicator and Internet Explorer browsers to run the same Java code with the same results. We explored the processes used by Communicator and Explorer to download and install Java Plug-in. We also explored the Java Plug-in Control Panel. After briefly looking at the two Java consoles, we examined the <EMBED> and <OBJECT> tags. Finally, we took a brief look at the code behind this article's demonstration applet.

Not everything has been covered. If you examine the official documentation, you'll find information on JNI, disk caching, security, tag coexistence, and other topics. I encourage you to review this documentation, as listed in the Resources section.

Learn more about this topic

Join the discussion
Be the first to comment on this article. Our Commenting Policies