a case for reconsidering JEP 398: Deprecate the Applet API for Removal
Alan Bateman
Alan.Bateman at oracle.com
Sun Apr 18 14:23:26 UTC 2021
On 17/04/2021 20:44, Alan Snyder wrote:
> :
> Although Applet may not be the most important compatibility issue, the proposed resolution (keep the class but rewrite the methods to throw an exception) seems harmless. Why not do that?
>
> Perhaps we need a new deprecation category: "deprecated for defunctionalization” (in other words, it is not removed but stops working).
>
> (Sorry about the odd terminology, but I was unable to think of a better term that could not be accused of being “politically incorrect”).
>
There are examples where terminally deprecated APIs have been
re-specified to work in a "degraded way" before eventually being
removed. Thread.stop(Throwable) was mentioned in one of the replies
here. That one was deprecated in Java 1.2, terminally deprecated and
re-specified to throw UOE in Java 9, and eventually removed in Java 11.
Thread.countStackFrames() is following a similar path. It was deprecated
in Java 1.2, terminally deprecated and re-specified to throw UOE in
Java 14 and will eventually be proposed to be removed too.
So yes, in some cases at least, it is possible to create a more gentle
off ramp for legacy or abandoned code. It may be that JEP 277 needs a
successor, in the form of an Informational JEP, to provide more up to
date guidelines on migration and timing of next steps after deprecating
an API for future removal. Most of mails on this thread don't seem to
concerned with JEP 398 but rather on some future JEP that will propose
to remove the Applet classes. It seems reasonable to use the intervening
period to explore migration options and see if it's worth leaving some
kind of carcass in place to keep the abandoned code running in
stand-alone code for a bit longer.
-Alan
More information about the jdk-dev
mailing list