Summary
-------

Remove the Applet API, which was [deprecated for removal in JDK 17][jep398] (2021). It is obsolete because neither recent JDK releases nor current web browsers support applets.

[jep398]: https://openjdk.org/jeps/398


Motivation
----------

- Web browsers no longer support applets.

- The Applet API and the `appletviewer` tool were [deprecated in JDK 9 via JEP 289](https://openjdk.org/jeps/289) (2017), when web-browser vendors were already removing support for applets.

- The `appletviewer` tool, which allowed applets to be tested without using a browser, was [removed in JDK 11](https://bugs.openjdk.org/browse/JDK-8200549) (2018). Since then, there has been no way to run applets using the JDK.

- The Applet API was [deprecated for removal in JDK 17 via JEP 398][jep398] (2021).

- The Security Manager, a necessary support pillar for running applets by sandboxing untrusted code, was [permanently disabled in JDK 24 via JEP 486](https://openjdk.org/jeps/486) (2025).

There is no reason to keep the unused and unusable Applet API.


Description
-----------

We will remove the following elements of the Java Platform API:

- The entire [`java.applet`] package, consisting of:

      java.applet.Applet
      java.applet.AppletContext
      java.applet.AppletStub
      java.applet.AudioClip

- These additional classes:

      java.beans.AppletInitializer
      javax.swing.JApplet

- Any remaining API elements that reference the above classes and interfaces, including methods and fields in:

      java.beans.Beans
      javax.swing.RepaintManager

[`java.applet`]: https://docs.oracle.com/en/java/javase/24/docs/api/java.desktop/java/applet/package-summary.html


Testing
-------

Any tests which rely on the Applet API will need to be updated, disabled, or removed. For `jtreg`-based tests in the main-line JDK repository, this work is almost complete. Most such tests merely use the Applet API for convenience; few of them explicitly test the API.


Risks and Assumptions
---------------------

- Given that it is largely unusable, there are no substantial risks to user applications in removing the Applet API.

- Code that still uses the Applet API will either stay on older releases or will migrate to some other API. In cases where the `Applet` class serves as a user-interface container component, the AWT API provides several alternatives.

- `java.net.URLConnection.getContent()` returns `java.lang.Object` and does not specify the specific type that will returned for any content type. However where the content represents audio data recognized by the JDK, it has always returned an instance of `java.applet.AudioClip`. This will no longer be possible, so this unspecified behavior must necessarily change to return some other type. Applications which cast the result to `AudioClip` will no longer compile or run. These applications will need to be updated.

- The [`jtreg`] tool references the Applet API, so it must be built using a JDK that still supports applets. This is required anyway, however, since `jtreg` must be able to test JDK release trains older than what the current `javac` compiler supports. At run time, `jtreg` only loads the Applet API when encountering an applet-based test, so a single `jtreg` build can support older JDK builds as well as newer builds which omit the Applet API.

[`jtreg`]: https://openjdk.org/projects/code-tools/jtreg/intro.html