a case for reconsidering JEP 398: Deprecate the Applet API for Removal
Mario Torre
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.
Cheers,
Mario
—
Mario Torre
Java Champion and OpenJDK contributor
PGP Key: 0BAB254E
Fingerprint: AB1C 7C6F 7181 895F E581 93A9 C6B8 A242 0BAB 254E
Twitter: @neugens
Web: https://www.mario-torre.eu/
Music: https://mario-torre.bandcamp.com/
More information about the jdk-dev
mailing list