The Java programming language and libraries enable you to create applets that are as simple or as complex as you like. In fact, you can write the simplest Java applet in only a few lines of code, as shown in Listing 1.
The first line of Listing 1 tells the Java compiler that this applet will be using some or all of the classes defined in the applet package (the asterisk acts as a wildcard, just as in DOS file names). All of the basic capabilities of an applet are provided for in these classes, which is why you can create a usable applet with so few lines of code.
The second line of code declares a new class called MyApplet. This new class is declared as public so that the class can be accessed when the applet is run in a Web browser or in the Appletviewer application. If you fail to declare the applet class as public, the code will compile fine, but the applet will refuse to run. In other words, all applet classes must be public.
The Five Stages of an Applet's Life Cycle
Every Java applet you create inherits a set of default behaviors from the Applet class. In most cases, these default behaviors do nothing, unless you override some of Applet's methods in order to extend the applet's basic functionality. However, although a simple applet like MyApplet in Listing 1 doesn't seem to do much, a lot is going on in the background. Some of this activity is important to your understanding of applets, and some of it can stay out of sight and out of mind.
Part of what goes on in a simple applet is the execution of the applet's life cycle. There are five parts to this cycle, each of which has a matching method that you can override to gain access to that cycle of the applet's life. The five stages of an applet's life cycle are listed here:
Initialization stage. This is the part of an applet's life cycle in which the applet object is created and loaded. At this point, it's appropriate to create objects needed by the applet, as well as initialize values that must be valid when the applet runs. The initialization stage occurs only once in the applet's life cycle. You can tap into the initialization stage by overriding the Applet class's init() method.
Start stage. This stage occurs when the system starts running the applet. The start stage can occur right after the initialization stage or when an applet is restarted. This usually happens when the user switches back to the applet's page after viewing a different page in his or her Web browser. Unlike the initialization stage, the start stage can occur several times over the life of the applet. To provide your own start code, override the Applet class's start() method.
Paint stage. The paint stage occurs whenever the applet's display must be drawn on the screen. This happens right after the applet's start stage, as well as whenever the applet's display must be restored or changed. This can happen when the applet is exposed from underneath another window or when the program changes the applet's display in some way and explicitly repaints the applet. Almost every applet you write will have a paint() method, which is the method you override to provide your applet with its display.
Stop stage. As you may have guessed, the stop stage is the counterpart to the start stage. Java executes this stage of the applet's life cycle when the applet is no longer visible on the screen, such as when the user switches to a different Web page. The default behavior for this cycle, however, is to keep the applet running in the background. If you want to handle the stop cycle differently, you should override the Applet class's stop() method.
Destroy stage. This is the counterpart to the initialization stage and occurs when the system is about to remove the applet from memory. Like the initialization cycle, the destroy cycle occurs only once. If your applet has resources that need to be cleaned up before the applet exits, this is the place to do it. You tap into this cycle by overriding the Applet class's destroy() method.
To be entirely accurate, the paint stage isn't considered an actual applet life cycle, but because an applet without a display is likely useless (not always, though), I thought I'd include the paint cycle. Truth is, the paint() method isn't even defined in the Applet class. Rather, Applet inherits paint() from the Component class, a superclass in Applet's long chain of inheritance, which goes from Applet to Panel to Container and finally to Component.
Example: Overriding the Life Cycle Methods
All this talk about life cycles and overriding methods may have left you a little confused as to how all this actually applies to the applets you want to create. In previous chapters, you managed to create applets without dealing with most of this stuff because the Applet class, from which you derived your own applet classes, handled the life-cycle methods in the default manner proscribed by the Java system. If you look at Listing 3, you'll see a small applet that overrides all the methods needed to provide custom behaviors for all the applet's life-cycle stages.
Listing 3 MyApplet2.java: Overriding the Applet Life-Cycle Methods.
public class MyApplet2 extends Applet
public void init()
// Place initialization cycle code here.
public void start()
// Place start cycle code here.
public void paint(Graphics g)
// Place paint cycle code here.
public void stop()
// Place stop cycle code here.
public void destroy()
// Place destroy cycle code here.
Notice that in order to override the paint() method, you must import the java.awt.* libraries, which contain information about the Graphics class. As you learned when writing previous applets in this book, the Graphics class enables you to display information and graphics in an applet's display area (or canvas, as the display area is sometimes called).
If you look for the previous methods in Java's source code, you'll discover that the default implementations of init(), start(), paint(), stop(), and destroy() all do nothing at all. If you want your applet to do something in response to these cycles, you have to provide the code yourself by overriding the appropriate method.