Loading an Applet
When an applet is been loaded, this is what happens:

• An instance of applet's controlling class is created.
• The applet gets initialized itself.
• The applet starts to run.

Leaving and Returning to Applet's Page
When user leaves the page -- say for example, to go to different page -- the applet has an option to stop by itself. When the user returns to the page, applet can do start by itself again. The same thing takes place when the user iconifies a browser window which contains the applet.

Reloading the Applet
Some browsers let the users to reload the applets, which consists of unloading applet and then loading it again. Before an applet is been unloaded, it is given the chance to stop itself and then perform the final cleanup, so that the applet can do release any of the resources it holds. After that the applet is unloaded and loaded as described in Loading the Applet, above.

Every applet can do run in multiple threads. example: when a HotJava browser first views the document that contains an applet, browser's DocumentSwitcher thread executes an applet's init() method. And when user scrolls the document, AWT WServer thread executes an applet's update() method.

So why would a applet need to create and use its own threads? Imagine an applet that performs the time-consuming initialization -- like loading images -- in its init() method. The thread which invokes the init() method cannot do anything else until the init() returns. In the HotJava browser, this means that browser cannot display applet or anything after it until the applet has finished the initializing itself. Therefoer if an applet is at the top of the page, then nothing would appear on the page until the applet has finished initializing itself.

The solution to this is to create a thread and move the initialization code from the init() method into thread body.

The Security Restrictions
For the security reasons, an applet which is loaded over network has the following restrictions:

• It cannot load the libraries or define native methods.
• It cannot ordinarily read or write the files on host that is executing it.
• It cannot make network connections except the host which it came from
• It cannot start any program on the host which is executing it.
• It cannot read every system property.
• Windows which an applet brings up look different than windows which an aplication brings up.

Each browser do have a SecurityManager object which checks for the applet security violations. When a SecurityManager detects violation, it throws up an SecurityException.

The Applet Capabilities
Here are some of the other things that an applet can do which you might not expect:

• Applets running within the Web browser can easily cause an HTML documents to be displayed.
• Applets can do invoke the public methods of other applets on same page.
• Applets that are loaded from local file system (from a directory in user's CLASSPATH) have none of the restrictions that applets loaded over the network do have.
• Although most of the applets stop running once you leave their page.

The java.applet package provides the API that gives an applets some capabilities which applications dont have. as an applets can play sounds, which other programs cannot do.