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

[Jan Schlößin]

Am 16.04.21 um 04:51 schrieb mark.yagnatinsky at barclays.com:
> I think talking about a "migration path" here is missing the point:
> I'm worried about stuff that has zero maintainers but non-zero users.
> So there's no one around to perform any migration.
> 
> Similarly, Mario's phrase "if you need to support a 20 years old [..] application" is missing the point:
> There is no one who "needs to support" anything.  There is no support.
> There are users who are benefiting from an application that exists and happens to work.
> One fine day it will stop working and there will be no one they can turn to.
> 
> If the users are programmers, it's not too hard to manually remove all mentions of the applet API and recompile.
> If the users are not programmers, then asking them to install a new JDK is pretty much the limit of technical sophistication that's reasonable to expect.
> (Unlike the old days, there's no user-friendly installer to install just a JRE.)
> 
> So I guess the real question is this: once Java 8 is unsupported, do we want people to download the latest JDK to run unmaintained Swing apps?
> Or do we expect users to keep their trusty Java 8 JRE's around, since JDK 23 won't work and JDK 17 will be unsupported by then anyway?

So we are talking about what removal means in that case. Do we have to
remove the class Applet or is it enough to replace all method bodies
with throwing UnsuportedOperationException?

I think I want to make a point for the fact that Java is famous for not
breaking old code and therefor IMHO such an empty Applet class could fly
around in the JDK for eternity without accumulating too much maintenance
time. We only have to document once, that this skeleton is there for
compatibility reasons with legacy code.

Regards, Jan