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

Tue Apr 6 10:50:18 UTC 2021

----- Mail original -----
> De: "Mark Rotteveel" <mark at lawinegevaar.nl>
> À: "jdk-dev" <jdk-dev at openjdk.java.net>
> Envoyé: Mardi 6 Avril 2021 11:16:43
> Objet: Re: a case for reconsidering JEP 398: Deprecate the Applet API for Removal

> Hi Remi,
> 
> You are ignoring the core of Mark's argument. It is not about using
> applets as such, but that there are unmaintained Swing applications in
> the wild that are implemented both as an applet and as a normal Java
> application. Removal of applet classes would therefor render those
> applications inoperable, even if they are not used as applets, but as
> normal applications.

Java loads classes lazily, so depending on how the the application is coded, it may not an issue at all because the VM has to load the applet code to see that the dependency is missing.
Again, we are talking about a post 2030 world and after that writing an agent that provides the necessary bits and bolts is always possible, if the application is popular enough.

> 
> Mark
> 

Rémi

> 
> On 2021-04-06 08:41, Remi Forax wrote:
>> Hi Mark,
>> As the JEP says, browsers don't support the applet API anymore,
>> the plugin API has been deprecated because it lacks any sandboxing.
>> Currently, the only way to see an applet is to use Internet Explorer on
>> Windows.
>> 
>> Anyway, this JEP is about tagging the Applet API with
>> @Deprecated(forRemoval = true),
>> so in the JDK 17, the applet API will still exist. Given that the JDK
>> 17 is a LTS, a long term support release,
>> you get at least 8 to 10 years of support, so you still be able to use
>> applets until 2030,
>> if Microsoft does not drop the support of Internet Explorer before.
>> 
>> regards,
>> Rémi
>> 
>> ----- Mail original -----
>>> De: "mark yagnatinsky" <mark.yagnatinsky at barclays.com>
>>> À: "jdk-dev" <jdk-dev at openjdk.java.net>
>>> Envoyé: Jeudi 1 Avril 2021 22:49:55
>>> Objet: a case for reconsidering JEP 398: Deprecate the Applet API for
>>> Removal
>> 
>>> Not sure what the proper etiquette for this list is, hope someone will
>>> tell me
>>> if I'm breaking any rules.
>>> 
>>> I'd like to make an argument against deprecating the applet API for
>>> removal.
>>> Namely, it used to be a common practice to write Swing apps in such a
>>> way that
>>> they can run either as an applet, or as a desktop application.
>>> There are thus all sorts of nice little jars floating around the web,
>>> which
>>> remain perfectly usable as desktop applications today,
>>> but would suddenly stop working on newer JDKs because they happen to
>>> have the
>>> magic words "extends Applet".
>>> (For instance, this one I've used personally that would probably
>>> break:
>>> http://www.science.smith.edu/~jorourke/books/CompGeom/CompGeom.html)
>>> These are often un-maintained so it's probably unrealistic to expect
>>> all of them
>>> to be "fixed".
>>> 
>>> Thus I propose that rather than removing the API's outright, one of
>>> the
>>> following options can be taken:
>>> 
>>> Option 1: do nothing: keep applets deprecated, but not for removal,
>>> and
>>> eventually stop testing or maintaining the relevant code.
>>> 
>>> Option 2: remove the bulk of the implementation, leaving just enough
>>> so that
>>> code that mentions the applet AIP can compile and run successfully.
>>> This is a little bit tricky, in that you have to figure out what
>>> counts as a
>>> "workable stub".
>>> For instance, the applet constructor can't be changed to
>>> unconditionally throw
>>> an exception since the "extends Applet" trick mentioned above results
>>> in calling that constructor even when running as a desktop app.
>>> 
>>> That's my two cents.
>>> 
>>> Thanks,
>>> Mark.
>>> 
>>> _________________________________________________________________________________________________________________________________________________________________________________________________________________________________
>>> This message is for information purposes only, it is not a
>>> recommendation,
>>> advice, offer or solicitation to buy or sell a product or service nor
>>> an
>>> official confirmation of any transaction. It is directed at persons
>>> who are
>>> professionals and is not intended for retail customer use. Intended
>>> for
>>> recipient only. This message is subject to the terms at:
>>> www.barclays.com/emaildisclaimer.
>>> 
>>> For important disclosures, please see:
>>> www.barclays.com/salesandtradingdisclaimer regarding market commentary
>>> from
>>> Barclays Sales and/or Trading, who are active market participants;
>>> https://www.investmentbank.barclays.com/disclosures/barclays-global-markets-disclosures.html
>>> regarding our standard terms for the Investment Bank of Barclays where
>>> we trade
>>> with you in principal-to-principal wholesale markets transactions; and
>>> in
>>> respect of Barclays Research, including disclosures relating to
>>> specific
>>> issuers, please see http://publicresearch.barclays.com.
>>> _________________________________________________________________________________________________________________________________________________________________________________________________________________________________
>>> If you are incorporated or operating in Australia, please see
>>> https://www.home.barclays/disclosures/importantapacdisclosures.html
>>> for
>>> important disclosure.
>>> _________________________________________________________________________________________________________________________________________________________________________________________________________________________________
>>> How we use personal information  see our privacy notice
>>> https://www.investmentbank.barclays.com/disclosures/personalinformationuse.html
> >> _________________________________________________________________________________________________________________________________________________________________________________________________________________________________