You should see “initializing … starting … ” above, as the result of the applet being loaded. When an applet is loaded, here’s what happens:

When the user leaves the page—for example, to go to another page—the browser stops the applet. When the user returns to the page, the browser starts the applet.

Some browsers let the user reload applets, which consists of unloading the applet and then loading it again. Before an applet is unloaded, it’s given the chance to stop itself and then to perform a final cleanup, so that the applet can release any resources it holds. After that, the applet is unloaded and then loaded again, as described in the Loading the Applet section (page 549).

When the user quits the browser (or whatever application is displaying the applet), the applet has the chance to stop itself and do final cleanup before the browser exits.

An applet can react to major events in the following ways:

The next section describes the four applet methods that correspond to these four types of reactions.

Not every applet needs to override every one of these methods. Some very simple applets override none of them. For example, the “Hello World” applet (page 6) doesn’t override any of these methods, since it doesn’t do anything except draw itself.

The “Hello World” applet just displays a string once, using its paint method. (The paint method is described on page 552.) Most applets, however, do more.

The init method is useful for one-time initialization that doesn’t take very long. In general, the init method should contain the code that you would normally put into a constructor. The reason applets shouldn’t usually have constructors is that an applet isn’t guaranteed to have a full environment until its init method is called. For example, the Applet image-loading methods simply don’t work inside of an applet constructor. The init method, on the other hand, is a great place to call the image-loading methods, since the methods return quickly.

Every applet that does something after initialization (except in direct response to user actions) must override the start method. The start method either performs the applet’s work or (more likely) starts up one or more threads to perform the work. You’ll learn more about threads in the Threads in Applets section (page 585). You’ll learn more about handling the events that represent user actions in the Methods for Drawing and Event Handling section (page 552).

Most applets that override start should also override the stop method. The stop method should suspend the applet’s execution so that it doesn’t take up system resources when the user isn’t viewing the applet’s page. For example, an applet that displays animation should stop trying to draw the animation when the user isn’t looking at it.

Many applets don’t need to override the destroy method, since their stop method (which is called before destroy) does everything necessary to shut down the applet’s execution. However, destroy is available for applets that need to release additional resources.

To draw the applet’s representation within a browser page, you use the paint method.

For example, the Simple applet defines its onscreen appearance by overriding the paint method:

public void paint(Graphics g) {
  // Draw a Rectangle around the applet's display area.
  g.drawRect(0, 0,
    getWidth() - 1,
    getHeight() - 1);

  // Draw the current string inside the rectangle.
  g.drawString(buffer.toString(), 5, 15);
}

Applets inherit the paint method from the Abstract Window Toolkit (AWT) Container class.

Applets inherit a group of event-handling methods from the Container class.

The Container class defines several methods, such as processKeyEvent and processMouseEvent, for handling particular types of events, and then one catch-all method called processEvent.

To react to an event, an applet must override the appropriate event-specific method. For example, the following program, SimpleClick,^[10] implements a MouseListener and overrides the mouseClicked method:

/*
 * Java(TM) SE 6 version.
 */

import java.awt.event.MouseListener;
import java.awt.event.MouseEvent;
import java.applet.Applet;
import java.awt.Graphics;

// No need to extend JApplet, since we don't add
// any components; we just paint.
public class SimpleClick extends Applet
    implements MouseListener {

  StringBuffer buffer;

  public void init() {
    addMouseListener(this);
    buffer = new StringBuffer();
    addItem("initializing... ");
  }

  public void start() {
    addItem("starting... ");
  }

  public void stop() {
    addItem("stopping... ");
  }

  public void destroy() {
    addItem("preparing for unloading...");
  }

  void addItem(String newWord) {
    System.out.println(newWord);
    buffer.append(newWord);
    repaint();
  }
  public void paint(Graphics g) {
    // Draw a Rectangle around the applet's display area.
    g.drawRect(0, 0,
               getWidth() - 1,
               getHeight() - 1);

    // Draw the current string inside the rectangle.
    g.drawString(buffer.toString(), 5, 15);
  }

  // The following empty methods could be removed
  // by implementing a MouseAdapter (usually done
  // using an inner class).
  public void mouseEntered(MouseEvent event) {
  }
  public void mouseExited(MouseEvent event) {
  }
  public void mousePressed(MouseEvent event) {
  }
  public void mouseReleased(MouseEvent event) {
  }

  public void mouseClicked(MouseEvent event) {
    addItem("click!... ");
  }
}

Run the resulting applet^[11] (Figure 18.3). When you click within its rectangle, it displays the word “click! …”.

Figure 18.3. A screenshot of the SimpleClick applet.

Swing supplies the following UI components (the class that implements each component is listed in parentheses):

Because the JApplet class inherits from the AWT Container class, it’s easy to add components to applets and to use layout managers to control the components’ onscreen positions. Here are some of the Container methods an applet can use:

To make the Simple applet use a scrolling, non-editable text field, we can use the JTextField class. Here is the revised ScrollingSimple class:^[13]

/*
 * Java(TM) SE 6 version.
 */

import javax.swing.JApplet;
import javax.swing.JTextField;
import javax.swing.SwingUtilities;

// Since we're adding a Swing component, we now need to
// extend JApplet. We need to be careful to access
// components only on the event-dispatching thread.
public class ScrollingSimple extends JApplet {

  JTextField field;

  public void init() {
    // Execute a job on the event-dispatching thread:
    // creating this applet's GUI.
    try {
        SwingUtilities.invokeAndWait(new Runnable() {
          public void run() {
            createGUI();
          }
        });
    } catch (Exception e) {
        System.err.println("createGUI didn't " +
                           "successfully complete");
    }
    addItem(false, "initializing... ");
  }

  private void createGUI() {
    // Create the text field and make it uneditable.
    field = new JTextField();
    field.setEditable(false);

    // Set the layout manager so that the text field will be
    // as wide as possible.
    setLayout(new java.awt.GridLayout(1,0));

    // Add the text field to the applet.
    add(field);
  }
  public void start() {
    addItem(false, "starting... ");
  }

  public void stop() {
    addItem(false, "stopping... ");
  }

  public void destroy() {
    addItem(false, "preparing for unloading...");
    cleanUp();
  }

  private void cleanUp() {
    // Execute a job on the event-dispatching thread:
    // taking the text field out of this applet.
    try {
        SwingUtilities.invokeAndWait(new Runnable() {
          public void run() {
            remove(field);
          }
        });
    } catch (Exception e) {
        System.err.println("cleanUp didn't " +
                           "successfully complete");
    }
    field = null;
  }

  private void addItem(boolean alreadyInEDT, String newWord) {
    if (alreadyInEDT) {
        addItem(newWord);
    } else {
        final String word = newWord;
        // Execute a job on the event-dispatching thread:
        // invoking addItem(newWord).
        try {
            SwingUtilities.invokeAndWait(new Runnable() {
              public void run() {
                addItem(word);
              }
            });
        } catch (Exception e) {
            System.err.println("addItem didn't " +
                               "successfully complete");
        }
    }
  }
  // Invoke this method ONLY from the event-dispatching thread.
  private void addItem(String newWord) {
    String t = field.getText();
    System.out.println(newWord);
    field.setText(t + newWord);
  }
}

The createGUI method creates an uneditable text field (a JTextField instance). It sets the applet’s layout manager to one that makes the text field as wide as possible (you can learn about layout managers in Laying Out Components within a Container^[14]) and then adds the text field to the applet.

Run the resulting applet^[15] (Figure 18.5).

Figure 18.5. A screenshot of the ScrollingSimple applet.

Every browser implements security policies to keep applets from compromising system security. This section describes the security policies that current browsers adhere to. However, the implementation of the security policies differs from browser to browser. Also, security policies are subject to change. For example, if a browser is developed for use only in trusted environments, then its security policies will likely be much more lax than those described here.

Current browsers impose the following restrictions on any applet that is loaded over the network:

Each browser has a SecurityManager object that implements its security policies. When a SecurityManager detects a violation, it throws a SecurityException. Your applet can catch this SecurityException and react appropriately.

The java.applet package provides an API that gives applets some capabilities that applications do not have.

Here are some other things that current browers and other applet viewers let applets do:

The getApplet method looks through all of the applets on the current page to see if one of them has the specified name. If so, getApplet returns the applet’s Applet object.

By default, an applet has no name. For an applet to have a name, one must be specified in the HTML code that adds the applet to a page. You can specify an applet’s name in two ways:

Two applets^[19] illustrate lookup by name (Figures 18.9 and 18.10). The first, the Sender, looks up the second, the Receiver. When the Sender finds the Receiver, the Sender sends a message to the Receiver by invoking one of the Receiver’s methods (passing the Sender’s name as an argument). The Receiver reacts to this method call by changing its leftmost text string to “Received message from sender-name!”.

Figure 18.9. A screenshot of the Sender applet.

Figure 18.10. A screenshot of the Receiver applet.

The code the Sender program^[20] uses to look up and communicate with the Receiver is listed below. Code that you can use without change in your own applet is in bold font:

Applet receiver = null;
String receiverName = nameField.getText(); // Get name
                                           // to search for.
receiver = getAppletContext().getApplet(receiverName);

The Sender goes on to make sure that the Receiver was found and that it’s an instance of the correct class (Receiver^[21]). If all goes well, the Sender sends a message to the Receiver:

if (receiver != null) {
  // Use the instanceof operator to make sure the applet
  // we found is a Receiver object.
  if (!(receiver instanceof Receiver)) {
      status.appendText("Found applet named " +
                        receiverName + ", " +
                        "but it's not a Receiver object.
");
  } else {
      status.appendText("Found applet named " +
                        receiverName + ".
" +
                        " Sending message to it.
");
      // Cast the receiver to be a Receiver object
      // (instead of just an Applet object) so that the
      // compiler will let us call a Receiver method.
      ((Receiver)receiver).processRequestFrom(myName);
  }
} ...

From an applet’s point of view, its name is stored in a parameter named NAME. It can get the value of the parameter using the Applet getParameter method. For example, Sender gets its own name with the following code:

myName = getParameter("NAME");

For more information on using getParameter, see the Writing the Code to Support Parameters section (page 573).

The example applets in this section perform one-way communication—from the Sender to the Receiver. If you want your receiver to be able to send messages to the sender, then you just need to have the sender give a reference to itself (this) to the receiver. For example:

((Receiver)receiver).startCommunicating(this);

The getApplets method returns a list (an Enumeration,^[22] to be precise) of all the applets on the page. For security reasons, many browsers and applet viewers implement getApplets so that it returns only those applets that originated from the same host as the applet calling getApplets. Run an applet that simply lists all the applets it can find on this page (Figure 18.11).^[23]

Figure 18.11. A screenshot of the GetApplets applet.

Below are the relevant parts of the method that calls getApplets:^[24]

public void printApplets() {
  // Enumeration will contain all applets on this page
  // (including this one) that we can send messages to.
  Enumeration e = getAppletContext().getApplets();
  ...
  while (e.hasMoreElements()) {
    Applet applet = (Applet)e.nextElement();
    String info = ((Applet)applet).getAppletInfo();
    if (info != null) {
        textArea.appendText("- " + info + "
");
    } else {
        textArea.appendText("- " +
                           applet.getClass().getName() + "
");
    }
  }
  ...
}

Below are the sound-related Applet methods. The two-argument form of each method takes a base URL, which is usually returned by either getDocumentBase or getCodeBase, and the location of the sound file relative to the base URL:

The AudioClip interface defines the following methods:

Run an applet called SoundExample^[26] that illustrates a few things about sound (Figure 18.12). Note that, for instructional purposes, the applet adds up to 10 seconds to the load time for each sound. If the sounds were larger or the user’s connection slower than ours, these delays might be realistic.

Figure 18.12. A screenshot of the SoundExample applet.

The SoundExample applet provides an architecture for loading and playing multiple sounds in an applet. For this reason, it is more complex than necessary. Essentially, the sound loading and playing code boils down to this:

AudioClip onceClip, loopClip;
onceClip = applet.getAudioClip(getCodeBase(), "bark.au");
loopClip = applet.getAudioClip(getCodeBase(), "train.au");
onceClip.play();     // Play it once.
loopClip.loop();     // Start the sound loop.
loopClip.stop();     // Stop the sound loop.

Since there’s nothing more annoying than an applet that continues to make noise after you’ve left its page, the SoundExample applet stops playing the continuously looping sound when the user leaves the page and resumes playing it when the user comes back. It does this by implementing its stop and start methods as follows:

public void stop() {
  // If one-time sound were long, we'd stop it here, too.
  // looping is a boolean instance variable that's initially
  // false. It's set to true when the "Start sound loop" button
  // is clicked and to false when the "Stop sound loop" or
  // "Reload sounds" button is clicked.
  if (looping) {
    loopClip.stop();    // Stop the sound loop.
  }
}
public void start() {
  if (looping) {
    loopClip.loop();    // Restart the sound loop.
  }
}

The SoundExample applet features three classes:

Preloading the sounds in a background thread (with SoundLoader) improves the perceived performance by reducing the amount of time the user has to wait to be able to interact with the applet. It does this by reducing the amount of time spent in the init method. If you simply called getAudioClip in the applet’s init method, it could take quite a while before getAudioClip returned, meaning that the applet couldn’t perform the other statements in its init method, and that the applet’s start wouldn’t get called. (For this SoundExample applet, a delay in calling the start method doesn’t matter.)

Another advantage of loading the sounds in a background thread is that it enables the applet to respond appropriately (and immediately) to user input that would normally cause a sound to play, even if that sound hasn’t been loaded yet. If you simply use the Applet play method, for example, then the first time the user does something to make the applet play a particular sound, the applet’s drawing and event handling are frozen while the sound is loaded. Instead, this applet detects that the sound hasn’t been loaded yet and responds appropriately.

This example is discussed in more detail in the Threads in Applets: Examples section (page 586).

This section guides you through the four questions you should ask as you implement parameters:

It ends with a discussion of the parameters defined in a sample <APPLET> tag.

<APPLET CODE=SampleApplet.class CODEBASE=example
  WIDTH=350 HEIGHT=60>
<PARAM NAME=windowClass VALUE=BorderWindow>
<PARAM NAME=windowTitle VALUE="BorderLayout">
<PARAM NAME=buttonText
  VALUE="Click here to see a BorderLayout in action">
</APPLET>

Applets use the Applet getParameter method to get user-specified values for applet parameters. The getParameter method is defined as follows:

public String getParameter(String name)

Your applet might need to convert the string that getParameter returns into another form, such as an integer. The java.lang package provides classes such as Integer that you can use to help with converting strings to primitive types. Here’s an example of converting a parameter’s value into an integer:

int requestedWidth = 0;
...
String windowWidthString = getParameter("WINDOWWIDTH");
if (windowWidthString != null) {
  try {
      requestedWidth = Integer.parseInt(windowWidthString);
  } catch (NumberFormatException e) {
      // Use default width.
  }
}

Note that if the user doesn’t specify a value for the WINDOWWIDTH parameter, the above code uses a default value of 0, which the applet interprets as “use the window’s natural size.” It’s important that you supply default values wherever possible.

Besides using the getParameter method to get values of applet-specific parameters, you can also use getParameter to get the values of attributes of the applet’s <APPLET> tag. See the Using the applet Tag section (page 595) for a list of <APPLET> tag attributes.

Now that you’ve provided all those nice parameters to the user, you need to help the user set the parameter values correctly. Of course, your applet’s documentation should describe each parameter and give the user examples and hints about setting them. Your job doesn’t stop there, though. You should also implement the getParameterInfo method so that it returns information about your applet’s parameters. Browsers can use this information to help the user set your applet’s parameter values.

Below is an example of implementing the getParameterInfo method:

public String[][] getParameterInfo() {
  String[][] info = {
    // Parameter Name  Kind of Value  Description
    {"imagesource",    "URL",         "a directory"},
    {"startup",        "URL",         "displayed at startup"},
    {"background",     "URL",         "displayed " +
                                             "as background"},
    {"startimage",     "int",         "start index"},
    {"endimage",       "int",         "end index"},
    {"namepattern",    "URL",         "used to generate " +
                                             "indexed names"},
    {"pause",          "int",         "milliseconds"},
    {"pauses",         "ints",        "milliseconds"},
    {"repeat",         "boolean",     "repeat or not"},
    {"positions",      "coordinates", "path"},
    {"soundsource",    "URL",         "audio directory"},
    {"soundtrack",     "URL",         "background music"},
    {"sounds",         "URLs",        "audio samples"},
  };
  return info;
}

As you can see, the getParameterInfo method must return an array of three-String arrays. In each three-String array, the first string is the parameter name. The second string gives the user a hint about what general kind of value the applet needs for the parameter. The third string describes the meaning of the parameter.

Some applets let the user customize the applet’s configuration with parameters, as described in the Defining and Using Applet Parameters section (page 570). For example, AppletButton (an applet used throughout this tutorial to provide a button that brings up a window) allows the user to set the button’s text by specifying the value of a parameter named BUTTONTEXT.

The developer provides the value of a parameter using a <PARAM> tag. The <PARAM> tags should appear just after the <APPLET> tag for the applet they affect:

<APPLET CODE=AppletSubclass.class WIDTH=anInt HEIGHT=anInt>
<PARAM NAME=parameter1Name VALUE=aValue>
<PARAM NAME=parameter2Name VALUE=anotherValue>
</APPLET>

Here’s an example of the <PARAM> tag in use.

<APPLET CODE="Animator.class" WIDTH=460 HEIGHT=160>
<PARAM NAME="imageSource" VALUE="images/Beans">
<PARAM NAME="backgroundColor" VALUE="0xc0c0c0">
<PARAM NAME="endImage" VALUE=10>
<PARAM NAME="soundSource" VALUE="audio">
<PARAM NAME="soundtrack" VALUE="spacemusic.au">
<PARAM NAME="sounds"
  VALUE="1.au|2.au|3.au|4.au|5.au|6.au|7.au|8au|9.au|0.au">
<PARAM NAME="pause" VALUE=200>
...
</APPLET>

Note the ellipsis points (“...”) in the previous HTML example. What did the example leave out? It omitted alternate HTML code-HTML code interpreted only by browsers that don’t understand the <APPLET> tag. Alternate HTML code is any text that appears between the <APPLET> and </APPLET> tags, after any <PARAM> tags. Browsers enabled with Java technology ignore alternate HTML code.

To specify alternate text to browsers enabled with Java technology and other browsers that understand the <APPLET> tag, use the ALT attribute. If the browser can’t display an applet for some reason, it can display the applet’s ALT text.

We use alternate HTML code throughout the online version of this tutorial to tell readers about the applets they’re missing. Often, the alternate HTML code includes one or more pictures of the applet. Here’s the complete HTML code for the Animator example shown previously:

<APPLET CODE="Animator.class" WIDTH=460 HEIGHT=160
  ALT="If you could run this applet, you'd see some animation">
<PARAM NAME="imageSource" VALUE="images/Beans">
<PARAM NAME="backgroundColor" VALUE="0xc0c0c0">
<PARAM NAME="endImage" VALUE=10>
<PARAM NAME="soundSource" VALUE="audio">
<PARAM NAME="soundtrack" VALUE="spacemusic.au">
<PARAM NAME="sounds"
  VALUE="1.au|2.au|3.au|4.au|5.au|6.au|7.au|8au|9.au|0.au">
<PARAM NAME="pause" VALUE=200>
Your browser is completely ignoring the &lt;APPLET&gt; tag!
</APPLET>

A browser that doesn’t understand the <APPLET> tag ignores everything in the previous HTML code except the line that starts with “Your”. A browser that does understand the <APPLET> tag ignores everything on that line. If the applet-savvy browser can’t run the applet, it might display the ALT text.

By default, a browser looks for an applet’s class and archive files in the same directory as the HTML file that has the <APPLET> tag. (If the applet’s class is in a package, then the browser uses the package name to construct a directory path underneath the HTML file’s directory.) Sometimes, however, it’s useful to put the applet’s files somewhere else. You can use the CODEBASE attribute to tell the browser in which directory the applet’s files are located:

<APPLET CODE=AppletSubclass.class CODEBASE=aURL
  WIDTH=anInt HEIGHT=anInt>
</APPLET>

If aURL is a relative URL, then it’s interpreted relative to the HTML document’s location. By making aURL an absolute URL, you can load an applet from just about anywhere—even from another HTTP server.

This book uses CODEBASE="someDirectory/" frequently, since we group the examples for each chapter in subdirectories. For example, here’s the <APPLET> tag that includes the Simple applet in The Life Cycle of an Applet section (page 547):

<APPLET CODE=Simple.class CODEBASE="example/"
  WIDTH=500 HEIGHT=20>
</APPLET>

Figure 18.13 shows the location of the class file, relative to the HTML file, when CODEBASE is set to "example/".

Figure 18.13. Location of the class file when CODEBASE is set to "example/".

Figure 18.14 shows where the applet class can be if you specify an absolute URL for the value of CODEBASE.

Figure 18.14. Location of the class file when CODEBASE is set to an absolute URL.

If your applet has more than one file, you should consider providing an archive file that bundles the applet’s files into a single file. Whether archive files make sense for your applet depends on several factors, including your applet’s size, performance considerations, and the environment you expect your users to have.

Archive files reduce your applet’s total download time. Much of the time saved comes from reducing the number of HTTP connections that the browser must make. Each HTTP connection can take several seconds to start. This means that for a multifile applet, connection time can dwarf transfer time. You can further reduce transfer time by compressing the files in your archive file.

If you specify one or more archive files, then the applet class loader looks for the archive files in the same directory that it would search for the applet class file. The applet class loader then looks for the applet’s class files in the archive files. If a file isn’t in the archive, then the applet class loader generally tries to load it in the browser just as it would if the archive file weren’t present.

The standard Java archive format, called JAR, was introduced in JDK 1.1 and is based on the ZIP file format. You specify JAR files using the ARCHIVE attribute of the <APPLET> tag. You can specify multiple archive files by separating them with commas:

<APPLET CODE="AppletSubclass.class" ARCHIVE="file1, file2"
  WIDTH=anInt HEIGHT=anInt>
</APPLET>

Unfortunately, not all browsers understand the same archive format or use the same HTML code to specify the applet archive. Watch this page for the latest information about browser support for archives. To learn how to create a JAR file, see the Creating a JAR File section (page 490).

This section didn’t discuss every attribute of the <APPLET> tag. Other attributes—which might seem familiar, since the <IMG> HTML tag uses them—include ALIGN, VSPACE, and HSPACE. The <APPLET> tag also allows you to load a serialized (saved) applet by specifying the OBJECT attribute instead of specifying a class file with CODE. Finally, you can name an applet using the NAME attribute. For a detailed description of the <APPLET> tag, see the Using the applet Tag section (page 595).

This section discusses the few issues that are particular to applet GUIs. Some of the information in this section might not make sense until you’ve read the Creating a GUI with JFC/Swing and, in particular, the How to Make Applets section.^[31] That trail discusses all the GUI concepts referred to in this section:

Displaying diagnostics to the standard output can be an invaluable tool when you’re debugging an applet. Another time you’ll see messages at the standard output is when an uncaught exception occurs in an applet. Applets also have the option of using the standard error stream.

Where exactly the standard output and error are displayed varies, depending on how the applet’s viewer is implemented, what platform it’s running on, and (sometimes) how you launch the browser or applet viewer. When you launch the Applet Viewer from a UNIX shell window, for example, strings displayed to the standard output and error appear in that shell window, unless you redirect the output. When you launch the Applet Viewer from an X Windows menu, the standard output and error go to the console window.

Applets display to the standard output stream using System.out.print(String) and System.out.println(String). Displaying to the standard error stream is similar; just specify System.err instead of System.out. Here’s an example of displaying to the standard output:

// Where instance variables are declared:
boolean DEBUG = true;
...
// Later, when we want to print some status:
if (DEBUG) {
  System.out.println("Called someMethod(" + x + "," + y + ")");
}

You should be sure to disable all debugging output before you release your applet.

Applets can read the system properties listed in Table 18.1.

To read a system property from within an applet, the applet uses the System class method getProperty. For example:

String newline = System.getProperty("line.separator");

Run an applet^[34] which reads all of the properties available to all applets (Figure 18.17).

Figure 18.17. A screenshot of the GetOpenProperties applet.

You can find the source code in GetOpenProperties.java.^[35]

For security reasons, no existing browsers or applet viewers let applets read the system properties listed in Table 18.2.

This section discusses two examples of using threads in applets. The first applet, AnimatorApplet, shows how to use a thread to perform repeated tasks. The second applet this page discusses, SoundExample, shows how to use threads for one-time initialization tasks. SoundExample is featured in the Playing Sounds section (page 568).

This section does not explain basic thread code. To learn about the Java implementation of threads, refer to the Defining and Starting a Thread section (page 371).

public void start() {
  if (frozen) {
      // Do nothing. The user has requested that we
      // stop changing the image.
  } else {
      // Start animating!
      if (animatorThread == null) {
        animatorThread = new Thread(this);
      }
      animatorThread.start();
  }
}

public void stop() {
  animatorThread = null;
}

public void run() {
  ...
  while (Thread.currentThread() == animatorThread) {
    ...// Display a frame of animation and then sleep.
  }
}

This section talks about the client to be an applet.^[40] The client has been written not only to communicate with the host the applet came from, but also to have a graphical UI, and to have a loop so that it can get as many quotes as you like. You can run the applet by including it in a page with the following HTML code:

<APPLET CODE=QuoteClientApplet.class WIDTH=500 HEIGHT=100>
</APPLET>

The quoteApplet.html page^[41] contains the above HTML code. By saving this page to a file on your local HTTP server, you can use it to communicate with the server-side application that will be running on the HTTP server. You must also save the compiled form of the applet to the same directory.

Before the applet can get quotes, you need to run the server on the host that the applet came from. You then need to note the number of the port that the server is listening on. After you enter this port number into the applet, it will hook up with the server and you’ll be able to get one-line quotations. Below are detailed instructions, followed by pictures of the server and the applet in action:

Figure 18.19 shows a picture of the applet in action.

Figure 18.19. A screenshot of the QuoteServer applet.

As the What Applets Can and Can’t Do section (page 558) explains, applets are subject to many security restrictions. For example, they can’t perform file I/O, they can’t make network connections except to their original host, and they can’t start programs.

One way of working around these restrictions is to use a server application that executes on the applet’s host. The server won’t be able to get around every applet restriction, but it can make more things possible. For example, a server probably can’t save files on the host the applet’s running on, but it will be able to save files on the host the applet originated from.

This section features an example of a server that allows two applets to communicate with each other. The applets don’t have to be running on the same page, in the same browser, or on the same computer. As long as the applets originate from the same computer, they can communicate through the server that’s running on that originating computer. The example uses sockets, which are documented in All About Sockets.^[45]

Here are the source files:

The instructions for running the server are just like those for the previous example (see the A Simple Network Client Applet section, page 590). Run the server on the applets’ originating host, recording the port number that the applets should rendezvous on. Then initialize both applets (which can be running on different machines) to talk to the server port number. After this initialization is complete, type a string into each applet’s text field. Then press the Return key to send the message to the other applet.

Here’s the server in action:

www%  java TalkServer
TalkServer listening on rendezvous port: 36567

Figures 18.20 and 18.21 show pictures of the applets in action.

Figure 18.20. Sample talk output—machine #1.

Figure 18.21. Sample talk output—machine #2.

When deploying applets:

When deploying applets:

If you must deploy an applet in a mixed-browser environment, follow the guidelines in the Deploying Applets in a Mixed-Browser Environment section (page 598).

The classid attribute identifies which version of Java Plug-in to use.

The example shown below is the most commonly used form of the classid attribute. This example instructs Internet Explorer to use the latest installed version of Java Plug-in:

classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93"

Following is an alternative form of the classid attribute:

classid="clsid:CAFEEFAC-xxxx-yyyy-zzzz-ABCDEFFEDCBA"

In this form, “xxxx”, “yyyy”, and “zzzz” are four-digit numbers that identify the specific version of Java Plug-in to be used.

For example, to use Java Plug-in version 1.6.0, you specify:

classid="clsid:CAFEEFAC-0016-0000-0000-ABCDEFFEDCBA"

You use the optional codebase attribute to specify the location to download JRE from in case it is not installed on the system.

The codebase attribute has two forms:

Following is an example of how to use the codebase attribute to set up automatic downloads from the Sun Java Web site:

<object
  classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93"
  width="200" height="200"
  codebase="http://java.sun.com/update/1.6.0/
    jinstall-6-windows-i586.cab#Version=6,0,0,99">
  <param name="code" value="Applet1.class">
</object>

Sun has packaged each version of the JRE installer in Microsoft cabinet (.cab) file format. You can view a list of these releases and the corresponding .cab file names.^[52]

When using a pure HTML approach to deploy applets in a mixed-browser environment, note the following:

Consider the following example code from an HTML page:

<object classid="clsid:CAFEEFAC-0016-0000-0000-ABCDEFFEDCBA"
  <param name="code" value="Applet1.class">
    <comment>
      <embed code="Applet1.class"
             type="application/x-java-applet;jpi-version=1.6">
        <noembed>
          No Java Support.
        </noembed>
      </embed>
    </comment>
</object>

Instead of using the pure HTML approach described above, you can use JavaScript to deploy applets in a mixed-browser environment.

Through JavaScript, you:

In the following example, the document.write() method outputs either an embed or object tag for each user “on the fly”:

<html>
<script language="Javascript">

  var _app = navigator.appName;

  if (_app == 'Netscape') {
    document.write('<embed code="Applet1.class"',
      'width="200"',
      'height="200"',
      'type="application/x-java-applet;version=1.6">'),
    }
  else if (_app == 'Microsoft Internet Explorer') {
    document.write('<OBJECT ',
      'classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93"',
      'width="200"',
      'height="200">',
      '<PARAM name="code" value="Applet1.class">',
      '</OBJECT>'),
    }
  else {
    document.write('<p>Sorry, unsupported browser.</p>'),
    }

</script>
</html>

You can use the HTML Converter tool^[53] to help with generating object and embed tags for mixed environments.