a case for reconsidering JEP 398: Deprecate the Applet API for Removal

[Alan Bateman]

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