Summary

This lesson gave you lots of information -- almost everything you need to know to write a Java applet. This page summarizes what you've learned, adding bits of information to help you understand the whole picture.
First you learned that to write an applet, you must create a subclass of the java.applet Applet class. In your Applet subclass, you must implement at least one of the following methods: init(), start(), and paint(). The init() and start() methods, along with stop() and destroy(), are called when major events (milestones) occur in the applet's life cycle. The paint() method is called when the applet needs to draw itself to the screen.
The Applet class extends the AWT Panel class, which extends the AWT Container class, which extends the AWT Component class. From Component, an applet inherits the ability to draw and handle events. From Container, an applet inherits the ability to include other Components and to have a layout manager control their size and position. From Applet, an applet inherits much, including the ability to respond to major life-cycle events, such as loading and unloading. You'll learn more about what the Applet class provides as you continue along this trail.
You include applets in HTML pages using the <APPLET> tag. When a browser user visits a page that contains an applet, here's what happens:

The browser finds the class file for the applet's Applet subclass. The location of the class file (which contains Java bytecodes) is specified with the CODE and CODEBASE attributes of the <APPLET> tag.
The browser brings the bytecodes over the network to the user's computer.
The browser creates an instance ofApplet subclass. When we refer to an applet, we're generally referring to this instance.
The browser calls the applet's init() method. This method performs any one-time initialization that's necessary.
The browser calls the applet's start() method. This method often starts a thread to perform the applet's duties.

An applet's Applet subclass is its main, controlling class, but applets can use other classes, as well. These other classes can be either local to the browser, provided as part of the Java environment, or custom classes that you supply. When the applet tries to use a class for the first time, the browser tries to find the class on the host that's running the browser. If the browser can't find the class there, it looks for the class in the same place that the applet's Applet subclass came from. When the browser finds the class, it loads its bytecodes (over the network, if necessary) and continues executing the applet.
Loading executable code over the network is a classic security risk. For Java applets, some of this risk is reduced because the Java language is designed to be safe -- for example, it doesn't allow pointers to random memory. In addition, Java-compatible browsers improve security by imposing restrictions. These restrictions include disallowing applets from loading code written in any non-Java language, and disallowing applets from reading or writing files on the browser's host.

Overview of Applets