We seem to be talking past each other, at least slightly. My goal is NOT
to actually run applets.
Anyone who wanted to actually run applets should have complained to browser
vendors many years ago, as opposed to complaining to Java devs now.
My point is that there are many apps that were published with TWO entry
points
class Main extends javax.swing.JApplet { // entry point 1: be an applet
public static void main(String... argos){} // entry point 2: main method
}
By removing the applet API, we break use case #2, because the class loader
will fail to load Main because its parent class does not exist.
Note that this use case does not care about "testing coverage, performance,
bug reports, etc".
The applet API does not have to actually WORK, let alone work well.
It suffices for the classes to exist, so that class loading succeeds.
As for "make a runtime image that includes them, then tell people to
download that"... WHO should do this, exactly?
Certainly not the author of the applet! The whole worry is that the applet
is unmaintained!
The idea must then be that
1. some third party creates such a thing, and then
2. this becomes popular enough that someone with moderate skills in
Google-fu can find this thing once they notice they can't run their
favorite app anymore.
If nothing else, the wording in the JEP needs a bit of clarification to say
that this is indeed the hoped-for plan for these old apps.
Jep 504 is here: JEP 504: Remove the Applet API
<https://openjdk.org/jeps/504>
In the "risks and assumptions" section, it has this:
"Given that it is largely unusable, there are no substantial risks to user
applications in removing the Applet API."
The point I'm trying to make here is that there is indeed a substantial
risk, DESPITE the fact that it is indeed unusable!
And the "motivation" section makes a similar claim.
There should at the very least be a few words in the JEP that discuss the
breakage of non-applets.
I tried to bring this up on the jdk-dev list back when I heard about
deprecation for removal, here:
The jdk-dev April 2021 Archive by thread
<https://mail.openjdk.org/pipermail/jdk-dev/2021-April/thread.html#5283>
Back then, some folks seemed somewhat sympathetic. (Hmm... maybe I should
try that list again??)
For instance, Alan Bateman said
"It seems reasonable to use the intervening
period to explore migration options and see if it's worth leaving some
kind of carcass in place to keep the abandoned code running in
stand-alone code for a bit longer."
But as far as I can tell, nothing came of it.
At the very least it seems the JEP text should mention the problem?
On Mon, Nov 3, 2025 at 12:21 AM David Alayachew <[email protected]>
wrote:
> You're coming at this from the API and functionality perspective. I am
> saying to look at it from the testing coverage, performance, bug reports,
> etc. There are a lot of standards to maintain, and thus, A LOT that goes
> into maintaining the JDK. Being well contained only eases some parts of the
> effort.
>
> As for WebStart, yet another side of maintainability is security. WebStart
> could be (and has been) used to exploit vulnerabilities, so the reasons to
> remove it increased even further.
>
> As for running Applets, that should be very easy to do. Like you said,
> provide implementations for the classes and methods in the applet packages,
> make a runtime image that includes them, then tell people to download that.
> You can also build a launcher that calls the necessary Applet API's. While
> it won't be as straight forward as WebStart, it's still very easy to do.
>
> On Sun, Nov 2, 2025, 11:20 PM Mark Yagnatinsky <[email protected]> wrote:
>
>> Thanks for replying! I guess I'm not convinced that their "mere
>> existence" means that each feature needs to take them into account.
>> For one thing, they already don't work, and they are already deprecated.
>> They are also "well contained": the bulk of the API surface lives in just
>> one package (java.applet).
>> (Compare this to, say, the Security Manager, which really did have its
>> tendrils all over the place, or serialization, which still does.)
>>
>> I'm also not sure WebStart is quite analogous here. (Disclaimer: I know
>> roughly nothing about webstart; this may all be wrong.)
>> As far as I understand, all you need for web start to work is that some
>> program on your computer knows what to do with JNLP files.
>> Thus, it's perfectly practical for a third party to write such a program.
>> The only "tricky" part that I can think of is to ensure that the
>> javax.jnlp package exists even when running on newer versions of the JDK,
>> But since the JNLP launcher has full control of the classpath of the JVM,
>> it can indeed arrange for this.
>>
>> In the case of desktop apps that also happen to be applets, it's not
>> clear to me what to do; we no longer have a separate launcher.
>> Is the idea to create a jar file with the contents of the java.applet
>> package, and then tell people to always add it to their classpath?
>>
>> Either way, thanks for confirming the mailing list!
>> Mark.
>>
>> On Sun, Nov 2, 2025 at 8:55 PM David Alayachew <[email protected]>
>> wrote:
>>
>>> No, you are on the right mailing list.
>>>
>>> Let me start by saying -- I know how you feel. The way you feel about
>>> Applets is exactly how I felt about Java WebStart
>>> <https://en.wikipedia.org/wiki/Java_Web_Start>. I'm still cranky about
>>> it's removal.
>>>
>>> But to jump right into the point -- Deprecation for Removal means that
>>> the OpenJDK will no longer support this API, and thus, are removing it from
>>> the SDK.
>>>
>>> But that doesn't mean that the functionality is dead, just means that it
>>> won't be supported by the OpenJDK. My WebStart has found new life under
>>> OpenWebStart <https://openwebstart.com/>. I guarantee you that a
>>> similar thing will be made for Applets, as Applets went way further than
>>> Java WebStart ever did.
>>>
>>> And as for the reason, please remember that the existence of a feature
>>> means that it adds weight to the load. Java Applets could receive no
>>> changes whatsoever for the next 10 years, and yet *their mere existence* in
>>> the SDK contributes a large amount to the maintenance effort. And the
>>> reason why it adds so much to the maintenance effort is because Java must
>>> ensure that each feature or library they introduce is cohesive with the
>>> SDK. By keeping Applets in, that's one more thing that needs to be checked
>>> against. And Applets are large enough that this checking is non-trivial.
>>>
>>> I would encourage you (and those you come across) to look to Open Source
>>> Software solutions to the removal of Applets. You might be surprised how
>>> easy it is to achieve.
>>>
>>> On Fri, Oct 31, 2025 at 2:35 PM Mark Yagnatinsky <[email protected]>
>>> wrote:
>>>
>>>> In the olden days, it was pretty common to make apps that supported two
>>>> launch modes:
>>>> 1. entry point in main() created its own window using JFrame or
>>>> whatever.
>>>> 2. But also extend Applet so as to run in the browser.
>>>>
>>>> These days, the second mode no longer works because no browser supports
>>>> applets.
>>>> But the first mode still works fine. It would STOP working if the
>>>> applet API were removed.
>>>> (In particular, class loading would fail if the JVM can't find the
>>>> parent class.)
>>>>
>>>> Normally, when we talk about removing APIs, there is a simple bit of
>>>> messaging that goes something like this:
>>>> 1. This is hopefully a simple code change (e.g., stop extending Applet,
>>>> since it does you no good anyway).
>>>> 2. If you're not ready to make the code change, stay on an old version
>>>> for now
>>>> 3. If you're not going to be ready soon, use an LTS release.
>>>>
>>>> There's a cluster of vague implicit assumptions buried in such
>>>> messaging, such as:
>>>> 1. The application is actively maintained, or at least there exists a
>>>> person or group of people nominally in charge of maintaining it.
>>>> 2. The user and developer of the application are one and the same
>>>> person, or at least know each other or have some sort of business
>>>> relationship or SOMETHING.
>>>> 3. In short, it assumes that if the application doesn't run, the
>>>> developer has some reason to care. If the developer doesn't care, it's
>>>> presumably because the app has no users and hence nobody cares.
>>>>
>>>> In the case of the applet API, this is all largely false.
>>>> There are people who once upon a time put a cute little applet on the
>>>> web, and also made it runnable standalone.
>>>> If anyone happens to find this useful to them, then all the better, but
>>>> those people are not customers, just like someone is not your customer just
>>>> because they happen to read your blog.
>>>> In other words, if these cute little former applets stop working, the
>>>> original author has no incentive to care and might not even notice for many
>>>> years.
>>>>
>>>> But even though these are all unmaintained, it does not mean they are
>>>> unused!
>>>> They may indeed have users, possibly users who find them indispensable!
>>>> But those users may not have access to the code, and may not be
>>>> programmers even if they did have access.
>>>> To those users, removing the applet API means that these apps no longer
>>>> work on the latest JDK, and they have no one to complain to.
>>>>
>>>> For a while, they can stay on old JDK, but eventually this becomes
>>>> harder and harder as old JDK versions may not support new operating systems
>>>> and CPUs and stuff.
>>>> (Not everyone knows how to set up a VM and an emulator and stuff.)
>>>> Also, some people may be too nervous to run an old JVM that hasn't
>>>> gotten security updates in a long time.
>>>>
>>>> Conversely, consider the cost of keeping these APIs. They would still
>>>> be deprecated.
>>>> Nobody is filing bug reports against them, since they are unusable
>>>> anyway.
>>>> They are not "literally free" but the maintenance burden for the
>>>> OpenJDK team should be only marginally higher than the maintenance burden
>>>> of dead code.
>>>>
>>>> Thoughts?
>>>>
>>>> Thanks,
>>>> Mark.
>>>>
>>>
