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

mark.yagnatinsky at barclays.com mark.yagnatinsky at barclays.com
Mon Apr 5 23:51:24 UTC 2021


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 
_________________________________________________________________________________________________________________________________________________________________________________________________________________________________


More information about the jdk-dev mailing list