A Java applet is a special kind of Java program that a browser enabled with

Java technology can download from the internet and run. An applet is
typically embedded inside a web page and runs in the context of a browser.
An
applet
must
be
a
subclass
of
the java.applet.Applet class.
The Applet class provides the standard interface between the applet and the
browser environment.
There are some important differences between an applet and a standalone
Java application, including the following:

An applet is a Java class that extends the java.applet.Applet class.

A main() method is not invoked on an applet, and an applet class will

not define main().

Applets are designed to be embedded within an HTML page.

When a user views an HTML page that contains an applet, the code for
the applet is downloaded to the user's machine.

A JVM is required to view an applet. The JVM can be either a plug-in of

the Web browser or a separate runtime environment.

The JVM on the user's machine creates an instance of the applet class
and invokes various methods during the applet's lifetime.

Applets have strict security rules that are enforced by the Web
browser. The security of an applet is often referred to as sandbox
security, comparing the applet to a child playing in a sandbox with
various rules that must be followed.

Other classes that the applet needs can be downloaded in a single Java
Archive (JAR) file.

Architecture
Java Runtime Environment
With the Java Plug-in, applets are not run in the JVM inside the browser.
Instead, they are executed in a separate process. The same JVM process can
be shared between multiple applets, or applets may be placed into different
processes depending on whether the existing JVMs match the applet
requirements and have enough resources to execute the applet. An applet
can request specific version of JRE to be used and can specify what options
need to be passed to the JVM. An applet can also request to be executed in
the separate JVM.

The browser and the applet can still communicate with one another,
however. Existing APIs have been re-engineered to use process sockets, so
things continue to work as they did before, only better. This architecture
provides a number of benefits:

Applets that require different versions of the JRE can run

simultaneously.
Applets can specify JRE start-up parameters such as heap size. (A new
applet uses an existing JRE if it's requirements are a subset of an existing
JRE, otherwise, a new JRE instance is launched.);
The message-passing interfaces are written in Java, so they run on all
supported platforms, in the same way, so cross-browser compatibility is
enhanced.

With that architecture, a new JRE can be launched whenever it is needed. But
an applet will run in an existing JRE as long as:

a.
The JRE version required by the applet matches an existing JRE, and
b. The JRE's launch parameters satisfy the applet's requirements
Thread Considerations
A web browser's JavaScript interpreter engine is single thread. The Java Plugin is capable of managing multiple threads. The Java Plug-in creates a
separate worker thread for every applet. Applets themselves may be multithreaded. Applets making JavaScript to Java calls and vice versa should be
designed with the thread related issues in mind.
The following picture shows the thread interactions between the JavaScript
Interpreter, Java Plug-in and an applet (i.e. Java).

When the JavaScript interpreter is idle, the Java Plug-in executes a JavaScript
to Java call on the per applet worker thread (JavaScript Interpreter Not Busy
scenario).

When a Java to Javascript call is in progress and a JavaScript to Java call is

made, the latter is executed on the same thread that made the Java to
JavaScript call (Round Trip scenario).
When a thread is executing a Java to JavaScript call, another thread wanting
to do the same will be blocked till the first thread has received its result and
is done (JavaScript Interpreter Busy scenario)
In order to avoid thread related issues especially when multiple applets are
running simultaneously, keep both Java to JavaScript and JavaScript to Java
calls short and avoid round trips, if possible.
Classloader Cache and Interaction between Applets
Normally, if two applets have the same codebase and archive parameters,
they will be loaded by the same class loader instance. This behavior is
required for backward compatibility, and is relied on by several real-world
applications. The result is that multiple applets on the same web page may
access each others' static variables at the Java language level, effectively
allowing the multiple applets to be written as though they comprised a single
application.
While this feature enables certain kinds of applications to be conveniently
written, it has certain drawbacks. It interferes with termination of applets, in
particular when multiple instances of the same applet are active. It makes
the programming model for applets more complex, since it is under specified
exactly when the static fields of an applet will be re-initialized, and when
they will be maintained from run to run of the same applet. It causes
imprecise behavior of certain user interface operations within the Java Plugin due to the inability to identify exactly which applet initiated a particular
request.
For this reason, the Java Plug-in provides a way to opt out of the use of
the classloader cache on an applet by applet basis.
Applet Garbage Collection
Garbage collection occurs on an applet instance immediately after
the destroy method finishes. The garbage collection applies to all memory
acquired by the applet, except for static variables. Statics are preserved in
the classloader cache, along with the classes themselves, for as long as the
class loader is present.
So when does the class loader go away? That behavior is not specified. It's
up to the implementation of the Java virtual machine and its interactions with
the operating system. You can expect it be retained for as long as possible,
but to be discarded when the memory is needed for other purposes.

Applet Privileges
All applets should be signed with a certificate from a recognized certificate
authority. The user must agree to run an applet and having a valid certificate
provides the user with some assurance that the applet is safe to run. An
applet runs in a secure sandbox that prevents it from interacting with the
users system, unless authorized. To obtain that authorization, the applet
must request permissions when it is launched and the user must agree to run
the applet. Permissions are needed to:

Print
Access the file system

Access browser cookies

Access other system resources

What Applets Can and Cannot Do

Java applets are loaded on a client when the user visits a page containing an
applet. The security model behind Java applets has been designed with the
goal of protecting the user from malicious applets.
Applets are either sandbox applets or privileged applets. Sandbox applets
are run in a security sandbox that allows only a set of safe operations.
Privileged applets can run outside the security sandbox and have extensive
capabilities to access the client.
Applets that are not signed are restricted to the security sandbox, and run
only if the user accepts the applet. Applets that are signed by a certificate
from a recognized certificate authority can either run only in the sandbox, or
can request permission to run outside the sandbox. In either case, the user
must accept the applet's security certificate, otherwise the applet is blocked
from running.
It is recommended that you launch your applet using Java Network Launch
Protocol (JNLP) to leverage expanded capabilities and improve user
experience. See Deploying an Applet for step by step instructions on applet
deployment.
It is recommended that you deploy your applets to a web server, even for
testing. To run applets locally, add the applets to the exception site list,
which is managed from the Security tab of the Java Control Panel.
In this topic we will discuss the security restrictions and capabilities of
applets.

Sandbox Applets
Sandbox applets are restricted to the security sandbox and can perform the
following operations:

They can make network connections to the host and port they came
from. Protocols must match, and if a domain name is used to load
the applet, the domain name must be used to connect back to the
host, not the IP address.
They
can
easily
display
HTML
documents
using
the showDocument method of the java.applet.AppletContext class.

They can invoke public methods of other applets on the same page.

Applets that are loaded from the local file system (from a directory
in the user's CLASSPATH) have none of the restrictions that applets
loaded over the network do.

They can read secure system properties.

When launched by using JNLP, sandbox applets can also perform the
following operations:
o

They can open, read, and save files on the client.

They can access the shared system-wide clipboard.

They can access printing functions.

They can store data on the client, decide how applets should
be downloaded and cached, and much more. See JNLP API for
more information about developing applets by using the JNLP
API.

Sandbox applets cannot perform the following operations:

They cannot access client resources such as the local filesystem,

executable files, system clipboard, and printers.
They cannot connect to or retrieve resources from any third party
server (any server other than the server it originated from).

They cannot load native libraries.

They cannot change the SecurityManager.

They cannot create a ClassLoader.

They cannot read certain system properties.

Properties for a list of forbidden system properties.

See System

Privileged applets
Privileged applets do not have the security restrictions that are imposed on
sandbox applets and can run outside the security sandbox.

Applet Hierarchy

Applet Life Cycle

Applet runs in the browser and its lifecycle method are called by JVM at its birth, its death and
when it is momentarily away.
Every Applet can be said to be any of the following state
1. New Born state
2.

Running state

3.

Idle state (may or may not)

4.

Dead state

The following figure represents the life cycle of the Applet

New Born State

The life cycle of an applet is begin on that time when the applet is first loaded into the
browser and called the init() method.

The init() method is called only one time in the life cycle on an applet.

The init() method is basically called to read the PARAM tag in the html file.

The init () method retrieve the passed parameter through the PARAM tag of html file using get
Parameter() method .

All the initialization such as initialization of variables and the objects like image, sound file are
loaded in the init () method .

After the initialization of the init() method user can interact with the Applet
Syntax:
public void init()
{
Statements
}
Running State

After initialization, this state will automatically occur by invoking the start method of applet
class which again calls the run method and which calls the paint method.

The running state also occurs from idle state when the applet is reloaded.

This method may be called multiples time when the Applet needs to be started or restarted.

For Example if the user wants to return to the Applet, in this situation the start Method() of an
Applet will be called by the web browser and the user will be back on the applet.

In the start method user can interact within the applet.

Syntax:
public void start()
{
Statements
}
Idle State

The idle state will make the execution of the applet to be halted temporarily.

Applet moves to this state when the currently executed applet is minimized or when the user
switches over to another page.

At this point the stop method is invoked.

From the idle state the applet can move to the running state.

The stop() method can be called multiple times in the life cycle of applet Or should be called
at least one time.

For example the stop() method is called by the web browser on that time When the user
leaves one applet to go another applet
Syntax:
public void stop()
{
Statements
}
Dead State

When the applet programs terminate, the destroy function is invoked which makes an applet
to be in dead state.

The destroy() method is called only one time in the life cycle of Applet like init() method.
Syntax:
public void destroy()
{

Statements
}
Display State

The applet is said to be in display state when the paint method is called.

This method can be used when we want to display output in the screen.

This method can be called any number of times.

paint() method is must in all applets when we want to draw something on the applet window.

paint() method takes Graphics object as argument

Syntax:
public void paint(Graphics g)
{
Statements
}
Example:
You can run this program, minimize the applet window and then maximize the window and see
the sequence of method calls.

1.

/*Program to illustrate the sequence of method call when an applet is

loaded*/
2.
import java.applet.*;
3.
import java.awt.*;
4.
5.
/* <applet code="AppLife.class" width="200" height="200">
6.
</applet> */
7.
8.
public class AppLife extends Applet
9.
{
10.
String msg="The currently executing method";
11.
12.
public void init()
13.
{
14.
msg+="init()";
15.
}
16.
17.
public void start()
18.
{
19.
msg+="start()";
20.
}
21.
22.
public void stop()
23.
{
24.
msg+="stop()";
25.
}

26.
27.
28.
29.
30.
31.
32.

public void paint(Graphics g)

{
g.drawString(msg,100,100);
showStatus("Test applet");
}
}