JEP 504: Remove the Applet API
Owner | Philip Race |
Type | Feature |
Scope | SE |
Status | Targeted |
Release | 26 |
Component | client-libs / java.awt |
Discussion | client dash libs dash dev at openjdk dot org |
Effort | S |
Duration | S |
Relates to | JEP 289: Deprecate the Applet API |
JEP 398: Deprecate the Applet API for Removal | |
Reviewed by | Kevin Rushforth, Victor Dyakov |
Endorsed by | Kevin Rushforth |
Created | 2024/12/04 20:33 |
Updated | 2025/07/14 19:34 |
Issue | 8345525 |
Summary
Remove the Applet API, which was deprecated for removal in JDK 17 (2021). It is obsolete because neither recent JDK releases nor current web browsers support applets.
Motivation
-
Web browsers no longer support applets.
-
The Applet API and the
appletviewer
tool were deprecated in JDK 9 via JEP 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 (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 (2021).
-
The Security Manager, a necessary support pillar for running applets by sandboxing untrusted code, was permanently disabled in JDK 24 via JEP 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
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.
-
Applications that still use 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. -
The return type of the
getContent()
methods of thejava.net.URL
andjava.net.URLConnection
classes isjava.lang.Object
. The precise type of the returned object depends upon the type of the content; when using these methods, the caller must test the type of the returned object in order to make use of it.Historically, these
getContent()
methods have returned instances ofjava.applet.AudioClip
when the content is audio data recognized by the JDK’s built-in content handlers. With the removal of the Applet API, this will no longer be possible and instances of some other type will be returned. Code which casts the result of calling these methods toAudioClip
will no longer compile or run, and will require adjustment. -
The
jtreg
tool references the Applet API, so it must be built using a JDK that still supports applets. This is required anyway, however, sincejtreg
must be able to test JDK release trains older than what the currentjavac
compiler supports. At run time,jtreg
only loads the Applet API when encountering an applet-based test, so a singlejtreg
build can support older JDK builds as well as newer builds which omit the Applet API.