a case for reconsidering JEP 398: Deprecate the Applet API for Removal
mbien42 at gmail.com
Mon Apr 19 14:03:50 UTC 2021
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
>> (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.
I am wondering if the applet classes could be moved from java.desktop to
a separate deprecated/retired module prior to removal (opposite of
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.
More information about the jdk-dev