JEP draft: Remove the Terminally Deprecated Applet API

OwnerPhilip Race
TypeFeature
ScopeSE
StatusSubmitted
Releasetbd
Componentclient-libs / java.awt
EffortS
DurationS
Reviewed byKevin Rushforth, Victor Dyakov
Created2024/12/04 20:33
Updated2024/12/06 17:58
Issue8345525

Summary

Remove the Java Applet API, which has been deprecated for removal for some time, and is obsolete as neither current JDK nor current browsers support applets.

Motivation

The Applet API in JDK has no implementation, meaning there is no way to run an Applet using the JDK. Browsers no longer support Applets, and the appletviewer tool which allowed developers to test applets without a web browser plugin was removed in JDK 11. The Java Security Manager which was a necessary support pillar for running applets (by sandboxing untrusted downloaded code) is already effectively removed by JEP 486. Thus there is no reason to keep the unused and unusable Applet API.

History

In JDK 9 (released Sept. 21, 2017) the Applet API and the appletviewer tool were deprecated : JEP 289

In JDK 11 (released Sept 25, 2018) the appletviewer tool was removed : JDK-8200549

In JDK 17 (released Sept. 21, 2021) the Applet API was deprecated for removal : JEP 398

Description

Remove these classes and interfaces of the standard Java SE API:

The entire java.applet package consisting of :

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

And remove these classes :

java.beans.AppletInitializer
javax.swing.JApplet

And remove any API elements that reference the above classes and interfaces, including any remaining methods and fields in:

java.beans.Beans
javax.swing.RepaintManager
javax.naming.Context

Testing

Any tests which rely on the Applet API will need to be updated, disabled, or removed. For jtreg-based tests in the JDK repo this work is already almost complete. This mainly covers tests that 'incidentally' use the API for convenience, as very few explicitly test the API.

Risks and Assumptions

The most obvious risk is that there will be a testing gap due to not migrating all tests that 'incidentally' use the Applet API to main program tests, but as noted above most of this work has already been completed.

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 Applet is principally used as a Container UI component, AWT provides several alternative options. As in the case of applet tests using the jtreg test harness [https://openjdk.org/projects/code-tools/jtreg/intro.html], they can be migrated to main programs.

The jtreg tool references the Applet API, so must be built using a JDK that still supports Applets, but this is required anyway as it must be able to test older JDK release trains than current javac supports. And since at runtime, jtreg only needs the Applet API when encountering an applet-based test, a single jtreg build can support older JDKs as well as ones without the Applet API.