Java applet

Java applets
Company type	Software technology
Industry	Software, Web development
Founded	1995
Founder	Sun Microsystems
Area served	Cross-platform (Windows, FreeBSD, Unix, macOS, Linux)
Products	Java bytecode files for web-based applets

Java applets are compact programs created in the Java language or any language that compiles down to Java bytecode, distributed as Java bytecode files. First introduced with Java’s initial launch in 1995, applets were intended to operate inside a Java virtual machine (JVM) embedded within web browsers or specialized tools such as Sun’s appletviewer.

Once widely embraced for delivering interactive web experiences, Java applets facilitated advanced, hardware-accelerated 3D graphics and computation-heavy operations, outperforming early iterations of JavaScript. They offered cross-platform compatibility across Windows, FreeBSD, Unix, macOS, and Linux systems but were not supported on mobile platforms lacking the standard Oracle JVM; for instance, Android utilized its own runtime environment.

Starting in 2013, major web browsers began discontinuing support for NPAPI—the plugin architecture that enabled applets—leading to their practical obsolescence by 2017. In response, Java officially deprecated the Applet API with the release of Java 9 in 2017, signaling the end of formal maintenance.

Although Java was the predominant language for applet development, other JVM-compatible languages such as Jython, JRuby, Pascal, Scala, NetRexx, and Eiffel (through SmartEiffel) were also employed. Over time, advancements in JavaScript—including hardware-accelerated graphics via canvas, WebGL, and WebGPU—eroded the distinct benefits previously offered by Java applets for web-based graphical and computational tasks.

Overview

Applets enhance web applications by providing interactive capabilities beyond what HTML alone can deliver. They capture user mouse input and incorporate interface elements like buttons or check boxes to enable dynamic graphical updates triggered by user interactions. This functionality makes them well-suited for educational demonstrations and visualizations, with extensive online repositories covering topics from physics to cardiac physiology.

In addition to graphical roles, applets can serve as text input areas that offer cross-platform command-line interface access to remote systems. Although they may run in separate windows, their ability to manipulate content outside their designated area on a webpage is limited, reducing their effectiveness for general site-wide UI enhancements compared to other browser extension options. Applets also support playback of media formats not natively handled by browsers.

Web pages embedding applets can pass parameters to customize the applet’s behavior or appearance dynamically.

Before the introduction of HTML5, applets were commonly used to implement simple interactive effects such as mouseover highlights and navigation buttons due to the absence of mature CSS and JavaScript interface standards like the DOM. However, this approach was resource-heavy and generally discouraged even at that time.

Technical information

Java applets typically ran inside a sandbox environment within browsers, limiting their access to sensitive local resources like the file system. The applet code downloaded from a web server could be embedded directly into a webpage or launched in a separate window displaying the applet’s user interface.

Initially, applets loaded individual classes one by one, resulting in slow startup times due to numerous small files being fetched. The advent of .jar packaging allowed applets to be delivered as a single compressed archive file—similar in size to an image file—ranging from hundreds of kilobytes up to several megabytes.

Java’s system libraries and runtime environments maintain backward compatibility, ensuring that existing code continues to run smoothly on current and future versions of the Java virtual machine.

Comparable technologies

Numerous Java programmers have advocated for the use of Java Web Start as an alternative to applets. Java Web Start executes unaltered applet code in a distinct window separate from the web browser.

While a Java Servlet is occasionally informally referred to as a server-side applet, it differs considerably in terms of programming language, purpose, and attributes.

Incorporation into web pages

Applets were integrated into websites using the now-obsolete applet HTML tag or the preferred object tag. Mozilla-based browsers also supported the embed element, which could define the applet’s source file and its placement. Both object and embed tags had the capability to download and install the Java Virtual Machine if it was not already present or to redirect users to the plugin installation page. Furthermore, starting from certain versions, the applet and object tags allowed initialization of serialized applets in predefined states and provided fallback content if the applet failed to execute.

Although by 2010 the object element was officially endorsed, inconsistent support across browsers led Sun Microsystems to continue recommending the legacy applet tag for deployment across multiple browsers, as it maintained broader compatibility. Employing object for cross-browser support often necessitated additional JavaScript for browser identification, extra browser-specific markup, or server-side adjustments.

The Java browser plug-in relied on NPAPI, a technology that most modern browsers have phased out due to security vulnerabilities and obsolescence concerns. In January 2016, Oracle declared that Java Runtime Environments built on JDK 9 would no longer include support for the browser plug-in.

Benefits

Java applets presented several advantages relevant to business applications:

They facilitated easy deployment across platforms such as FreeBSD, Linux, Windows, and macOS, with broad browser compatibility through the early 2000s; however, this support has diminished over time due to security issues.
A single applet could operate across all installed Java versions simultaneously rather than relying solely on the latest plug-in; requiring an updated Java Runtime Environment (JRE) could result in significant download delays for users.
Browsers cached applets to accelerate reload times, and once the JVM was active, subsequent applets launched rapidly—although newer JRE releases introduced restrictions limiting this behavior for security purposes.
Shifting computational tasks from servers to client machines enhanced scalability as user demand increased.
Unlike standalone applications that demand backward compatibility on servers, browsers automatically retrieved and cached the most recent applet version, reducing maintenance expenses related to legacy support.
Applets inherently handled dynamic user states effectively, such as maintaining game progress or session information.
Development and debugging processes were simplified within standard Java SE environments by invoking lifecycle methods independently before testing within browsers.
Untrusted applets operated within a tightly controlled sandbox environment, offering improved security compared to native executables; signed applets could request permission to access local resources with user approval.
Performance levels were comparable with native applications, enabling responsive enterprise-level software solutions.

Drawbacks

Java applets encountered significant obstacles compared to alternative client-side technologies:

The necessity for a sophisticated JRE and browser plug-in hindered widespread use, particularly within organizations where installing software required administrator consent.
Users frequently faced delays when downloading substantial JRE updates mandated by certain applets.
Mobile operating systems such as iOS and Android never supported Java applets, and desktop browsers gradually eliminated support in parallel with the rise of mobile platforms.
The absence of standardized support for screen readers impeded compliance with accessibility requirements.
Security limitations restricted the capabilities of untrusted applets; expanding their system access was only possible through manual adjustments to security policies.
The differentiation between trusted and untrusted applets often confused users and was ultimately removed to enhance security prior to the discontinuation of applets.

Compatibility-related lawsuits

Sun Microsystems emphasized preserving compatibility across different Java versions, enforcing portability standards when necessary. Oracle has upheld this commitment.

1997: Sun vs Microsoft

In 1997, Sun filed a lawsuit against Microsoft after the latter released a customized Java Virtual Machine bundled with Internet Explorer. Microsoft introduced approximately 50 additional methods and fields within the java.awt, java.lang, and java.io packages, eliminated RMI support, and replaced JNI with RNI to favor its DCOM technology. These modifications caused applets dependent on these features to function solely on Microsoft's JVM, thereby breaching Java’s cross-platform guarantee. Sun pursued legal action for trademark infringement; Microsoft settled by paying $20 million and agreeing to license Java in an unaltered form for a defined period.

2002: Sun vs Microsoft

Microsoft persisted in distributing its outdated Java VM as the default within Internet Explorer. As a result, many applets incorporated their own implementations of newer components such as Swing due to this lag. In 2002, Sun initiated an antitrust lawsuit accusing Microsoft of monopolistic behavior detrimental to the Java ecosystem. Sun demanded that Microsoft include Sun’s official Java implementation with Windows and cease distributing its own VM after the expiration of the previous license. The settlement required Microsoft to pay $700 million for antitrust claims, $900 million for patents, and a $350 million royalty fee for future use of Sun’s software.

Security

Java applets were categorized into two types with distinct security frameworks: signed and unsigned. From Java SE 7 Update 21 (April 2013), it became recommended that applets and Web-Start applications be signed using a trusted certificate, with warnings issued for unsigned applets. Beginning with Java 7 Update 51, unsigned applets were blocked by default but could be enabled by adding exceptions via the Java Control Panel.

Unsigned

Unsigned applets operated under stringent restrictions: they lacked access to local file systems, were permitted web access only to their originating download site, and faced prohibitions on accessing system properties, class loaders, native code execution, external commands, or redefining core Java classes. They executed within standalone windows marked as untrusted. Security mechanisms verify the entire call stack to prevent unauthorized method invocations from introducing vulnerabilities.

Despite ongoing security patches since Java's inception, certain vulnerabilities remained undiscovered for extended periods or were exploited by malicious software. Some reports indicate that unsigned applets may cause browser instability or excessive CPU consumption; however, these are typically minor issues rather than severe defects. Nonetheless, unsigned applets can be components in composite attacks exploiting other system weaknesses.

Executing unsigned applets on their hosting servers carries potential risks because they might bypass firewall protections or attempt denial-of-service (DoS) attacks; however, such risks are generally mitigated since administrators usually control both server and applet environments. Conducting code audits and isolating applet domains help manage these threats.

Unsigned applets could download malware from their source servers but were limited to temporary storage without execution privileges. Attempts to propagate exploits like Phoenix and Siberia through applets failed because these exploits did not depend on Java and had alternative distribution channels.

Signed

A signed applet carries a digital signature that is authenticated by an external, trusted certificate authority server. Generating this signature involves specialized software and collaboration with the certificate authority. After the user verifies and consents to the signature, the applet obtains enhanced privileges comparable to those of standalone applications, as the creator’s identity is confirmed and accountable. This allows applets to execute operations beyond standard client-side scripting; however, it requires users to make informed trust decisions. Potential issues include unavailability of the authority server, inaccurate verification of the signer’s identity, and exploitation by trusted publishers. Consequently, despite their introduction in Java 1.1, signed applets can still raise security concerns.

Self-signed

Self-signed applets bear signatures created by their own developers and may present security vulnerabilities. Java plugins alert users when such applets request permission because their authenticity is not validated by an external entity. These are commonly utilized during development phases, but most developers prefer obtaining third-party signatures to establish user confidence.

The security challenges faced by Java are similar to those encountered by other client-side technologies, such as Microsoft ActiveX. Since 2014, widely used Java plugins and Java Web Start have blocked self-signed and unsigned applets, compelling developers to acquire certificates from recognized commercial authorities.

Alternatives

Modern technologies like WebAssembly and JavaScript now provide capabilities equal to or surpassing those of applets. JavaScript can operate alongside applets on the same webpage, facilitating their launch or interaction. With advancements in JavaScript’s performance and functionality, support for applets gradually diminished until they were ultimately discontinued.

External links

Download the latest Sun Microsystems Java Virtual Machine (includes browser plug-ins for executing Java applets)
Oracle’s tutorial on creating applets
Sample applets and source code from Sun Microsystems (JDK 1.4)