I hear you, but it was already removed over 3 months ago :
https://bugs.openjdk.org/browse/JDK-8359053.
Removing applet can't be without pain, and it has taken about 10 years
of signalling to get here.
The cost of keeping these APIs is non-zero and keeping them for ever
whilst deprecating for removal is odd.
As for mixed main/applet programs, I know about that usage model. I've
done the same myself.
Although the only reason I've done so, was so that something that was
primarily an applet could
be tested / debugged more easily. In other words if something was
intended to be a standalone
application, I would never introduce a dependency on the applet package.
I'm not personally aware of any case of an applet that's still important
after 25 years and
yet no one has the source code. If you have source, migration should not
be hard.
If you don't, then staying on JDK 25 is an option which will get you
well past 2030.
That's some 4 more years than was originally anticipated when there were
thoughts of removing it in the JDK 17 time frame.
I'm sceptical that any such case of lost source would also need JDK 26
or later.
-phil.
On 11/2/25 8:20 PM, Mark Yagnatinsky 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.
