Threads in Applets

The Java^TM Tutorial

Start of Tutorial > Start of Trail > Start of Lesson

Search
Feedback Form

Trail: Writing Applets
Lesson: Practical Considerations when Writing Applets

Threads in Applets

Note: This page assumes that you know what a thread is. If you don't, read What Is a Thread? before reading this page.

Every applet can run in multiple threads. Applet drawing methods (paint and update) are always called from the AWT drawing and event handling thread. The threads that the major milestone methods -- init, start, stop, and destroy -- are called from depends on the application that's running the applet. But no application ever calls them from the AWT drawing and event handling thread.
Many browsers allocate a thread for each applet on a page, using that thread for all calls to the applet's major milestone methods. Some browsers allocate a thread group for each applet, so that it's easy to kill all the threads that belong to a particular applet. In any case, you're guaranteed that every thread that any of an applet's major milestone methods creates belongs to the same thread group.
Below are two PrintThread applets. PrintThread is a modified version of SimpleApplet that prints the thread and thread group that its init, start, stop, destroy, and update methods are called from. (Actually, due to a Netscape Navigator 2.0 for Windows 95/NT bug, the following applets don't implement update. If you aren't using a PC that's running Netscape Navigator 2.0, you should be able to run the real example.) Here's the code for the hobbled example, and for the more interesting example. As usual, to see the output for the methods such as destroy that are called during unloading, you need to look at the standard output. See Displaying Diagnostics to the Standard Output and Error Streams for information about the standard output stream.

You can't run applets. Here's what you'd see if you could:

This figure has been reduced to fit on the page.
Click the image to view it at its natural size.

Note: Because some old browsers don't support 1.1, the above applet is a 1.0 version (here is the 1.0 code; here's the 1.1 code). To run the 1.1 version of the applet, go to example-1dot1/PrintThread.html. For more information about running applets, refer to About Our Examples.
So why would an applet need to create and use its own threads? Imagine an applet that performs some time-consuming initialization -- loading images, for example -- in its init method. The thread that invokes init can not do anything else until init returns. In some browsers, this might mean that the browser can't display the applet or anything after it until the applet has finished initializing itself. So if the applet is at the top of the page, for example, then nothing would appear on the page until the applet has finished initializing itself.
Even in browsers that create a separate thread for each applet, it makes sense to put any time-consuming tasks into an applet-created thread, so that the applet can perform other tasks while it waits for the time-consuming ones to be completed.

Rule of Thumb: If an applet performs a time-consuming task, it should create and use its own thread to perform that task.

Applets typically perform two kinds of time-consuming tasks: tasks that they perform once, and tasks that they perform repeatedly. The next page gives an example of both.

Start of Tutorial > Start of Trail > Start of Lesson

Search
Feedback Form