The Applet Lifecycle
An applet has no main method, so it never decides for itself when to start doing work.
Instead, its host container - a browser plugin in the applet's original design, or
appletviewer when you're following along today - calls a fixed set of methods on your
applet class at well-defined moments. Together these five methods make up the applet
lifecycle. Understanding exactly when each one fires, and which ones can fire more
than once, is the single most important concept in this entire track.
The Five Lifecycle Methods
| Method | Runs... | Purpose |
|---|---|---|
init() |
Once | One-time setup when the applet is first loaded - reading <param> values
from the HTML, loading images, allocating resources. |
start() |
Repeatable | Called every time the applet becomes visible/active - for example when the user navigates back to the browser tab containing it. Can run more than once over an applet's life. |
paint(Graphics g) |
Repeatable | Called whenever the applet needs to redraw itself - after start(), after being
resized, or after being uncovered by another window. Inherited from
java.awt.Component, not something unique to Applet, but always
taught alongside the lifecycle since it's where an applet actually does its visible work. |
stop() |
Repeatable | Called every time the applet is hidden - switching tabs away, minimizing the window. Good place to pause background work (animation threads, sounds) so it doesn't run needlessly while unseen. |
destroy() |
Once | Called once, immediately before the applet is permanently unloaded - release any resources
you allocated in init() here. |
Call Order
On first load, the container calls the methods in this order. If the user navigates away and back (or the applet is otherwise hidden and shown again) without the page being reloaded, the bracketed portion below repeats before the applet is eventually destroyed:
init() -> start() -> paint() -> [ stop() -> start() -> paint() ]* -> stop() -> destroy() once once as needed repeats each time hidden/shown once once
Notice that init() only ever appears once at the very start, and destroy()
only ever appears once at the very end. Everything between them - start(),
paint(), and stop() - can happen any number of times, in that
start/paint/stop rhythm, for as long as the applet remains on the page.
appletviewer as shown in
Environment Setup if you want to watch the console output
for yourself.
Observing the Order Yourself
The easiest way to internalize this order is to override all five methods with a
System.out.println call in each, run the applet with appletviewer, and watch
the console while you minimize and restore the viewer window (or switch away and back):
import java.applet.Applet;
import java.awt.Graphics;
public class LifecycleDemoApplet extends Applet {
public void init() {
System.out.println("init() called");
}
public void start() {
System.out.println("start() called");
}
public void paint(Graphics g) {
System.out.println("paint() called");
g.drawString("Watch the console!", 20, 30);
}
public void stop() {
System.out.println("stop() called");
}
public void destroy() {
System.out.println("destroy() called");
}
}
Compile it with javac LifecycleDemoApplet.java, reference it from a minimal HTML file the
same way you did in the previous lesson, and open it with appletviewer. You'll see
init(), start(), and paint() print immediately; minimizing and
restoring the viewer window prints stop() followed by another start() and
paint(); closing the viewer prints a final stop() followed by
destroy().
paint(Graphics g) is technically inherited from java.awt.Component, the same
method every AWT component (buttons, panels, frames) can override - it isn't special to
Applet. It's grouped with the lifecycle here purely because it's where an applet actually
renders its content, and it fires constantly alongside the other four methods.
init() and destroy() each run exactly once, bookending the
applet's life. start(), paint(), and stop() can each run
multiple times in between, following a start/paint/.../stop/start/paint/... rhythm driven entirely by
visibility changes, not by your own code.
PaintApplet, the running example this whole track builds on.