a case for reconsidering JEP 398: Deprecate the Applet API for Removal
neugens.limasoftware at gmail.com
Fri Apr 16 12:01:24 UTC 2021
> On 16. Apr 2021, at 10:35, Jan Schlößin <jan at schloessin.de> wrote:
> 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?
If it’s an API it needs to work. Removing is the only option.
Java Champion and OpenJDK contributor
PGP Key: 0BAB254E
Fingerprint: AB1C 7C6F 7181 895F E581 93A9 C6B8 A242 0BAB 254E
More information about the jdk-dev