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

[Michael Bien]

On 18.04.21 16:23, Alan Bateman wrote:
> 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

I am wondering if the applet classes could be moved from java.desktop to 
a separate deprecated/retired module prior to removal (opposite of 
incubation).

This would give the option to run code found on old master thesis CDs by 
adding this retired module to future JDKs - as long someone from the 
community is willing to maintain it (once its actually removed).

On the other hand there will be always the option to use java 8 to run 
retro jars for experiments, even after the support expired - old JDKs 
won't just disappear.

best regards,

michael