Why Java 26 Removes the Applet API: End of an Era

Mar 25, 2026

The Problem

I saw “Remove the Applet API” in the Java 26 JEP list and wondered: does anyone still use applets? Should I care about this removal? What if my old code references Applet classes?

The answer: unless you’re maintaining legacy systems from the early 2000s, this doesn’t affect you. But understanding why it happened helps you see where Java is heading.

What Was Removed?

JEP 504 removes these classes and interfaces from the JDK:

// These classes are gone in Java 26
java.applet.Applet
java.applet.AppletStub
java.applet.AppletContext
java.applet.AudioClip
javax.swing.JApplet
java.beans.AppletInitializer

// If your code references these, it won't compile on Java 26

These have been deprecated since JDK 9 (2017) and deprecated for removal since JDK 17 (2021). Java 26 finally removes them.

Why Applets Had to Die

Let me trace the timeline:

1995: Java Applets launched - revolutionary web technology
2000s: Peak adoption, then Flash competition
2013: Chrome announces NPAPI deprecation
2015: Firefox removes NPAPI support
2017: All major browsers drop NPAPI; JDK 9 deprecates Applet API
2021: JDK 17 marks for removal
2026: JDK 26 removes Applet API completely

The root cause: NPAPI (Netscape Plugin Application Programming Interface) died. Every major browser removed it:

Chrome: Removed NPAPI in 2015
Firefox: Dropped support in 2017
Edge: Never supported it (legacy Edge)
Safari: Disabled by default since 2017

Without NPAPI, applets can’t run. They’ve been zombies for nearly a decade.

The Security Problem

Even before browsers killed NPAPI, applets had security issues:

// Applets ran with restrictive permissions, but:
// - Sandbox escape vulnerabilities were common
// - Unsigned applets were blocked by default by 2014
// - Signed applets required user trust decisions
// - Users often clicked "Run" without understanding risks

// This was the common pattern that caused problems:
public class LegacyApplet extends Applet {
    public void init() {
        // Code running in browser context
        // Access to filesystem? Network? Depends on signing
    }
}

The plugin model itself was the problem. Browsers moved to safer extension models.

Impact on Developers

For most developers: zero impact.

If your code still references Applet classes, you’ll see compilation errors:

// This won't compile on Java 26:
import java.applet.Applet;

public class MyOldCode extends Applet {
    // Error: cannot find symbol: class Applet
}

But let’s be realistic: if you’re still using Applet classes in 2026, you have bigger problems than compilation errors.

Migration Paths

If you somehow have applet-dependent code, here are your options:

1. Java Web Start → jpackage

Java Web Start was also removed (JDK 11). The modern replacement is jpackage:

# Create a native installer for your application
jpackage --name MyApp \
  --input target/ \
  --main-jar myapp.jar \
  --main-class com.example.MyApp \
  --type dmg  # or exe, msi, rpm, deb

This creates a standalone application, not a browser plugin.

2. Applet UI → JavaFX

If you used applets for rich UI components:

// Old Applet approach (DEAD):
public class MyUIApplet extends JApplet {
    public void init() {
        // Swing UI code
    }
}

// Modern approach: JavaFX application
public class MyUIApplication extends Application {
    @Override
    public void start(Stage primaryStage) {
        // JavaFX UI code
        Scene scene = new Scene(new Label("Hello"), 400, 300);
        primaryStage.setScene(scene);
        primaryStage.show();
    }
}

3. Browser Integration → Web Technologies

If you needed browser embedding:

Old Way: Applet running in browser
         ↓
New Way: JavaScript + WebAssembly + Backend API

Java backend (Spring Boot, Quarkus, etc.)
      ↕ REST/WebSocket
Browser (React, Vue, plain JS)

This is what the industry did years ago.

Why This Removal Matters

The Applet API removal is part of a broader trend in Java:

Removing dead code: Less maintenance burden for OpenJDK developers
Smaller JDK: Reduced footprint for containers and cloud deployments
Clear deprecation path: Sets precedent for other removals

This is what “deprecated for removal” means. It’s not a warning - it’s a promise.

Deprecated (JDK 9)
    ↓
Deprecated for Removal (JDK 17)
    ↓
Removed (JDK 26)

What’s Next for Java Removals?

Looking at current deprecations, these might follow the same path:

Security Manager: Deprecated for removal in JDK 17
Nashorn JavaScript engine: Removed in JDK 15
Pack200 compression: Removed in JDK 14

The pattern is clear: Java removes unused, problematic, or superseded features to keep the platform healthy.

Summary

In this post, I covered why Java 26 removes the Applet API:

Why: Browsers killed NPAPI support by 2017, making applets non-functional
What: java.applet.* and javax.swing.JApplet classes removed
Impact: Minimal - applets haven’t worked for nearly a decade
Migration: Use jpackage for standalone apps, or migrate to web technologies

This removal is symbolic. It’s the formal end of Java’s first web technology. But practically? It’s cleaning up code that’s been dead for years.

Final Words + More Resources

My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me

Here are also the most important links from this article along with some further resources that will help you in this scope:

Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!