Platinum Edition Using HTML 4, XML, and Java 1.2
(Publisher: Macmillan Computer Publishing)
Author(s): Eric Ladd
ISBN: 078971759x
Publication Date: 11/01/98

paint()

The Java environment calls paint() whenever it suspects that the applet’s graphic space may have been obscured. As a result, paint() gets called far more often than you might expect. Experiment with the LifeCycle applet in various browsers to see when paint() gets called. Design your applets so that paint() is as efficient as possible—this method is where your program will spend much of its time.

destroy()

Put up Navigator’s Java Console, open a page with the LifeCycle applet on it, and exit Navigator. If you watch the console closely, you’ll see LiveCycle’s “destroy” message just before the console itself disappears. In general, browsers will try to keep applets around (at least in their stopped state) as long as they can. When the browser’s memory is full, or when the user exits the browser, the applet’s resources are released. Just before the browser destroys the applet’s memory, it calls destroy(). Use destroy() to release any resources your applet may have acquired.

Where’s the Destructor? If you’re experienced in C++, you may be puzzled by Java’s lack of a destructor. Java relies on garbage collection—you don’t have to explicitly delete objects. Nevertheless, your C++ habits will stand you in good stead—most programmers prefer to release resources as soon as they know they’re done with them. The code you put into destroy() should, therefore, resemble code you might write in a C++ destructor; look through your constructor and init() code, identify any resources (such as object references) you acquired, and release them. If your applet acquired other resources during its lifetime (such as nodes on a linked list), release them by setting the references to null.

You get a similar effect by writing a finalize() method. The garbage collector calls an object’s finalize() method just before the object’s memory is reclaimed. If you have a sophisticated applet with more than one class, you might want to write a finalize() method for each class that needs to dispose of resources. You can then use finalize() to dispose of system resources or perform other cleanup, and use destroy() to wrap up the applet itself.

Troubleshooting HelloApplet

Even with an applet as simple as this, a number of things could go wrong. Take a look at some common “gotchas”:

•  javac: Bad command or filename error—This message means that you didn’t install the JDK correctly.
If you are sure that you installed the JDK, all you need to do is set your DOS PATH. The easiest way to fix this problem is to make sure PATH and CLASSPATH are correctly defined in AUTOEXEC.BAT and then reboot your PC. Following is a sample AUTOEXEC entry:

PATH=c:\windows;c:\windows\command;c:\java\bin
CLASSPATH=c:\java\lib;.

Remember to use the Control Panel if you’re using Windows NT or a shell script if you’re on a UNIX system. You may need to restart your shell or command prompt window for this change to take effect. If you’ve changed AUTOEXEC.BAT, you need to run that batch file or reboot the machine.

•  Extraneous thread applet-HelloApplet.class find class HelloApplet messages—This message means that CLASSPATH is not defined correctly. The solution is the same as for the preceding problem: double-check your definitions for PATH and CLASSPATH and reboot your PC.
CLASSPATH consists of a list of directory paths in which appletviewer looks for Java classes. Each different pathname is separated by a semicolon. Make sure that the current directory (represented by a dot) is in your CLASSPATH list.

•  HelloApplet.java:26: Class gelloApplet not found in type declaration—This message or any similar-sounding compiler error probably means you mis-typed something.
Carefully double-check every place in the program where you meant to type the name in question (here, HelloApplet). Be sure each occurrence matches exactly (including capitalization—Java is case sensitive).
In this case, you carefully double-check your program and discover that you typed gelloApplet rather than HelloApplet. It compiles correctly after you make this correction.

•  HelloApplet.java:24: Warning: Public class HelloApplet must be defined in a file called HelloApplet.java—The name of your Java source file must match the name of your public Java class exactly.
For the sample program, this requirement means the class needs to be called HelloApplet, the source file needs to be called HelloApplet.java, and the HTML <APPLET> tag needs to specify HelloApplet.class, or your program will neither compile cleanly nor execute.
To fix this problem, carefully double-check everything for exact spelling and capitalization, and then compile again.

•  Nothing happens—If you are running Internet Explorer and you see the HTML, but not your applet, your browser probably is not configured to run Java. Choose View, Options, Security, and look at your Active Content group to make sure Java is enabled.
You must check the following:

•  Allow downloading of active content.

•  Enable Java programs. You should also set your browser’s Safety Level to Medium.

Sample Applets

Sometimes programming is better “caught than taught.” This section shows three fairly advanced applets—each uses techniques that haven’t been described in detail in this book. If you have a programming background, most of the logic of these applets should be clear; look in the Java documentation for details about the API. If you’d like a more detailed treatment of Java programming, read Using Java 1.2 (Que, 1998).