Applet Lifecycle in Java
Aconciseguidetothe applet lifecycle:how appletmethodscoordinate
initialization, execution, user interaction, and termination. Designed for
undergraduates and junior Java developers seeking a practical, example-
driven understanding.
Presented by = Vansh Garg
Utsav Jha
Tejas
Why the Lifecycle Matters
Defines when andhow resources areacquiredand released.
Ensures applet behaves correctly inside a browser or applet viewer.
Provides predictable hooks for animation, user input, and cleanup.
Theme colors: primary emphasis with #282824; backgrounds and accents use
#E8E4DD and #DED8CD for clarity.
Overview of Core Lifecycle Methods
init() start() paint(Graphics g)
One-time initialization: load resources, Called each time the applet becomes Rendering entry point — draw visuals;
set up UI components, prepare state. active — start threads, timers, or called by system and can be invoked
animations. via repaint().
stop() destroy()
Pauseongoing activity when applet is no longer active — Finalcleanup: release resources, close streams, stop threads
suspend threads, timers. permanently.
init() — Initialization
Purpose: runonce when the appletis firstloaded. Ideal for resource allocation
(images, fonts), UI setup, and reading parameters via getParameter().
Example (concise):
public void init() {
image = getImage(getCodeBase(), "[Link]");
setBackground([Link]);
// Initialize state
}
Keep init() fast. Heavy I/O can block loading — defer long tasks to a
background thread.
start() — Becoming
Active
Called afterinit(), and againwhenever the
applet becomes visible or gains focus. Use
start() to begin or resume animations, timers,
and threads.
Example:
public void start() {
animator = new Thread(this);
[Link]();
}
Pair stop() with start(): every active resource
started here should be paused in stop().
paint(Graphics g) — Rendering
paint()is theprimarydrawing method. The Graphics object provides drawing
primitives (lines, shapes, text, images). Keep painting code idempotent and fast;
avoid blocking calls.
Minimal example:
public void paint(Graphics g) {
[Link](g);
[Link]([Link]);
[Link](10, 10, 120, 80);
[Link]("Hello Applet", 20, 55);
}
Use repaint() to request a redraw; the system will schedule paint()
safely.
stop() and destroy() —
Pause and Cleanup
stop()
Called when the applet is no longer visible.
Suspend threads or animation timers here.
destroy()
Called once when the applet is unloaded.
Release resources, close files, null references.
Example cleanup snippet:
public void stop() {
running = false;
}
public void destroy() {
image = null;
// additional cleanup
}
Lifecycle Flow Diagram
load
init()
start()
paint() ↔ repaint()
This diagram highlights repeatable transitions: start() ↔ stop() during visibility changes; paint() is invoked repeatedly by the system or via
repaint(); destroy() is terminal.
Event Handling in Applets
Applets useAWT eventlisteners tohandleinput(mouse, keyboard, action
events). Register listeners during init() or start().
public void init() {
addMouseListener(new MouseAdapter() {
public void mousePressed(MouseEvent e) { /* handle
click */ }
});
}
Best practice: keep event handlers responsive; delegate heavy work to
worker threads and update UI via repaint().
Graphics & Animation — Practical Tips
Usedoublebufferingto prevent flicker:drawto anoffscreenimage,thendraw that image in
paint().
Control frame rate with a Timer or thread sleep inside start()/run().
Always stop animation in stop() to avoid background CPU usage.
Animation skeleton:
public void run() {
while (running) {
updateState();
repaint(); // schedules paint()
[Link](40); // ~25 FPS
}
}
For modern applications prefer Swing/AWT best practices or migrate to JavaFX — applets
are legacy but useful for learning lifecycle concepts.
Applets: Introduction
Compact overviewfor CS students and juniordevs— learn what Java applets
are, how they worked in browsers, their architecture, and where you might
still see the ideas today.
What is an Applet?
SmallJava program designedtorun inside a web browser or applet viewer
Typically extends [Link] or [Link]
Executed by the Java Virtual Machine (JVM) on the client side
No main() method — life-cycle managed by the container
Used for interactive UI elements embedded in web pages
History Snapshot
Createdby JamesGosling andtheSun Microsystems team (mid-1990s)
Introduced to enable rich interactivity inside web pages before widespread
JavaScript/HTML5
Gained traction via Netscape and plugin support
Security concerns and evolving web standards led to decline
Legacy influence: sandboxing, bytecode portability, and plugin architecture
Key Features of Java Applets
Writeonce, runanywhere:bytecodeportabilityacross JVMs
Sandboxed execution to limit file/network access (by default) Rich
UI support using AWT/Swing components Lifecycle callbacks:
init(), start(), stop(), destroy() Can interact with the hosting HTML
via LiveConnect (historically)
Applet vs Application
Aspect Applet Application
Execution Runs inside browser/JVM plugin Standalone JVM process
Entry Point No main(); uses lifecycle methods public static void main(String[])
Security Sandboxed by default Full system access (unless restricted)
Distribution Delivered via HTML & class/jar Installed or run directly
Use Cases Embedded UI, small interactions Full-featured desktop/server apps
Table shows core trade-offs — applets prioritized embedding and safety; applications prioritized capability and control.
Applet Architecture
AWT/Swing UI
Provides user interface
Security Manager
Enforces access policies
JVM
Executes bytecode and lifecycle
Applet Class
Loadedbytecode (class or JAR)
HTML Page
Container that embedstheapplet
Browser or viewer loads bytecode into the JVM, which enforces the SecurityManager and exposes UI via AWT/Swing. The container calls lifecycle methods
and mediates resources.
Types of Applets
Localapplets—loaded fromthesame
machine or trusted local source
Remote applets — downloaded from a
web server into the client JVM
Signed applets — digitally signed to
request elevated permissions
Unsigned remote applets run in strict
sandbox; signed can request
file/network access
Security model evolved — browsers
eventually removed plugin support
Structure of an Applet Program
Import packages: [Link].*, [Link].* or [Link].*
Class extends Applet or JApplet
Lifecycle methods: public void init(), start(), stop(), destroy()
Override paint(Graphics g) or use Swing components for UI
Bundle classes into a JAR for distribution and faster load
Sample Applet: Hello World
Concise example demonstrating lifecycle and drawing:
import [Link];
import [Link];
public class HelloApplet extends Applet {
public void init() {
// one-time setup
}
p u b l i c v o i d p a i n t ( G r a p h i c s g ) {
[Link]("Hello, Applet!", 50, 25);
}
}
Embed with <applet> or object tag historically; modern browsers no longer
support this by default.
Real-world Uses & Modern Lessons
Classic uses:browser games,calculators,interactivedemos, visualizations
Great for teaching UI concepts, event-driven programming, and graphics
APIs
Security and deployment lessons led to safer sandbox models and signed
code practices
Modern equivalents: Java Web Start (legacy), applets' ideas live on in
WebAssembly, HTML5 Canvas, and client-side frameworks
Takeaway: understand lifecycle, sandboxing, and portability — skills
transferable to contemporary web GUIs
Next steps: try converting the HelloApplet example to a Swing
application or a simple HTML5 Canvas demo to compare patterns.
Security Concerns in Java
Applets
Why Security is Important in Applets
Java applets, designedtorun withina webbrowser,introduceda powerful waytodeliverdynamiccontent. However, this power
came with inherent security risks. The ability of applets to execute code on a client's machine necessitated robust security measures
to protect users from malicious applets. Without proper security, an applet could potentially access sensitive local files, install
malware, or compromise the user's system, making the understanding and implementation of security paramount for their safe
deployment.
Java Applet Security Model
TheJava Applet SecurityModelwas built onthe principleof"sandbox
security." This model aimed to restrict the actions of untrusted code (applets)
to a confined environment, preventing them from performing operations that
could harm the host system. This foundational model relied on several key
components working in concert to enforce security policies and protect the
user's machine from potentially harmful applets.
Sandbox Environment
Applet
Untrustedcoderunning inside
Sandbox
Environment Protective Barrier
Isolatedexecutionspace for Enforces security restrictions
applets
Restricted Resources
Limited access to system APIs
The sandbox environment is a core concept of the Java security model. It creates a tightly controlled execution space for untrusted applets, isolating them from
the rest of the user's system. Within this sandbox, applets are granted limited permissions, preventing them from directly accessing local files, network resources
outside their origin, or other sensitive system functionalities. This isolation was crucial for allowing applets to run safely on diverse client machines without
requiring explicit user trust for every applet.
Restrictions on Unsigned Applets
Limited File Access Network Restrictions
Unsignedappletscouldnot read from or write to the local Theycouldonlyconnecttothe host from which they
file system. originated.
No System Properties Access No Native Code Execution
Accesstosystempropertieswasrestricted to prevent Unsignedappletswerepreventedfrom calling native
information leakage. methods.
Unsigned applets, those without a digital signature, operated under the strictest security policies within the sandbox. These
restrictions were put in place to minimize the potential damage an untrusted applet could inflict. The limitations ensured that even if a
malicious unsigned applet managed to bypass some checks, its capabilities would be severely curtailed, protecting the user's data and
system integrity.
Signed Applets and Digital
Certificates
Toovercomethe severe limitationsofunsigned applets, Javaintroduced
signed applets. A signed applet is packaged with a digital certificate from a
trusted authority, verifying the identity of the applet's publisher. When a user
encounters a signed applet, they are presented with a security warning that
identifies the publisher. If the user chooses to trust the publisher, the applet
can then be granted elevated privileges, allowing it to perform actions
outside the sandbox, such as accessing local files or connecting to arbitrary
network hosts. This mechanism shifted the trust decision from the applet
itself to its known publisher.
Security Mechanisms (Class Loader, Bytecode
Verifier, Security Manager)
Class Loader Bytecode Verifier Security Manager
Ensuresappletscannot load classes Checksapplet bytecode for integrity Enforcessecuritypolicies and
from unauthorized locations. and adherence to Java language rules. grants/denies access to system
resources.
The Java security architecture relied on a layered approach with several key mechanisms. The Class Loader was responsible for loading
applet classes into the Java Virtual Machine (JVM) and ensuring they came from trusted sources. The Bytecode Verifier performed static
analysis on the applet's bytecode to ensure it was well-formed and did not attempt to violate Java's type safety or memory access rules.
Finally, the Security Manager, a configurable component, enforced the runtime security policies, determining what actions an applet was
permitted to perform. These mechanisms worked together to create a robust defense against malicious code.
Common Security Threats
MaliciousCodeInjection:Appletscould becrafted toexecute harmful code if security checks were bypassed.
Information Disclosure: Vulnerabilities could allow applets to access sensitive user data from the local system.
Denial of Service (DoS): Malicious applets could consume excessive system resources, leading to system instability.
Phishing and Spoofing: Compromised applets could be used to mimic legitimate applications, tricking users into revealing
credentials.
Privilege Escalation: Exploits could allow an applet to gain higher permissions than intended, breaking out of the sandbox.
Despite the robust security model, Java applets were not immune to security threats. Attackers constantly sought vulnerabilities to
exploit, leading to various forms of attacks. These threats highlighted the ongoing challenge of securing dynamic content execution in
web browsers and the need for continuous vigilance and updates to security protocols.
Reasons for Decline of Applets
Security Vulnerabilities Complex Development
Frequent discovery of security flaws eroded user trust and made Developing and deploying applets was more complex than simpler web
applets a target for attackers. technologies.
Browser Plugin Dependency Lack of Mobile Support
Applets required a Java browser plugin, which often had compatibility Applets were not well-suited for the emerging mobile web, which
issues and security risks. favored lighter, more efficient technologies.
Rise of Alternative Technologies
Newer, more secure, and easier-to-use web technologies emerged,
offering better user experiences.
Performance Overhead
Java applets often had slower startup times and higher resource
consumption compared to native browser technologies.
The decline of Java applets was a multifaceted issue, driven by a combination of security concerns, technical limitations, and the rapid evolution of
web technologies. While innovative for their time, applets struggled to keep pace with the demands of a dynamic and increasingly security-
conscious internet. The reliance on browser plugins, in particular, became a significant hurdle as browsers moved towards more integrated and
secure content delivery.
Modern Alternatives
JavaScript HTML5 React
Theubiquitous language for interactive web Introducednew elements and APIs for rich media Apopular JavaScript library for building user
content, supported natively by all browsers. and interactive applications without plugins. interfaces, enabling complex single-page
applications.
Angular [Link]
Acomprehensive framework for building Aprogressive framework for building user
dynamic web applications. interfaces, known for its simplicity and flexibility.
The void left by Java applets was quickly filled by a new generation of web technologies that offered enhanced security, better performance, and a more
streamlined development experience. Modern web development now heavily relies on JavaScript, HTML5, and various frameworks like React, Angular,
and [Link] to deliver rich, interactive, and secure web applications directly within the browser, without the need for plugins.