<div dir="ltr"><div dir="ltr">So there's no plan to even update the JEP text to mention this stuff then?</div><div>(I admit staying on JDK 25 (or indeed JDK 8, which is when applets still "worked") is likely a viable option until somewhat past 2030.)</div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, Nov 3, 2025 at 2:23 PM Philip Race <<a href="mailto:philip.race@oracle.com">philip.race@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div>
I hear you, but it was already removed over 3 months ago :
<a href="https://bugs.openjdk.org/browse/JDK-8359053" target="_blank">https://bugs.openjdk.org/browse/JDK-8359053</a>.<br>
<br>
Removing applet can't be without pain, and it has taken about 10
years of signalling to get here.<br>
The cost of keeping these APIs is non-zero and keeping them for ever
whilst deprecating for removal is odd.<br>
<br>
As for mixed main/applet programs, I know about that usage model.
I've done the same myself.<br>
Although the only reason I've done so, was so that something that
was primarily an applet could<br>
be tested / debugged more easily. In other words if something was
intended to be a standalone<br>
application, I would never introduce a dependency on the applet
package.<br>
<br>
I'm not personally aware of any case of an applet that's still
important after 25 years and<br>
yet no one has the source code. If you have source, migration should
not be hard.<br>
If you don't, then staying on JDK 25 is an option which will get you
well past 2030.<br>
That's some 4 more years than was originally anticipated when there
were thoughts of removing it in the JDK 17 time frame.<br>
I'm sceptical that any such case of lost source would also need JDK
26 or later.<br>
<br>
-phil.<br>
<br>
<div>On 11/2/25 8:20 PM, Mark Yagnatinsky
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Thanks for replying! I guess I'm not convinced
that their "mere existence" means that each feature needs to
take them into account.
<div>For one thing, they already don't work, and they are
already deprecated.</div>
<div>They are also "well contained": the bulk of the API surface
lives in just one package (java.applet).</div>
<div>
<div>(Compare this to, say, the Security Manager, which really
did have its tendrils all over the place, or serialization,
which still does.)</div>
<div><br>
</div>
</div>
<div>I'm also not sure WebStart is quite analogous here.
(Disclaimer: I know roughly nothing about webstart; this may
all be wrong.)</div>
<div>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.</div>
<div>Thus, it's perfectly practical for a third party to write
such a program.</div>
<div>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,</div>
<div>But since the JNLP launcher has full control of the
classpath of the JVM, it can indeed arrange for this.</div>
<div><br>
</div>
<div>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.</div>
<div>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?</div>
<div><br>
</div>
<div>Either way, thanks for confirming the mailing list!</div>
<div>Mark.</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Sun, Nov 2, 2025 at 8:55 PM
David Alayachew <<a href="mailto:davidalayachew@gmail.com" target="_blank">davidalayachew@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div style="font-family:monospace">No,
you are on the right mailing list.</div>
<div style="font-family:monospace"><br>
</div>
<div style="font-family:monospace">Let
me start by saying -- I know how you feel. The way you
feel about Applets is exactly how I felt about <a href="https://en.wikipedia.org/wiki/Java_Web_Start" target="_blank">Java WebStart</a>.
I'm still cranky about it's removal.</div>
<div style="font-family:monospace"><br>
</div>
<div style="font-family:monospace">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.</div>
<div style="font-family:monospace"><br>
</div>
<div style="font-family:monospace">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 <a href="https://openwebstart.com/" target="_blank">OpenWebStart</a>. I guarantee you
that a similar thing will be made for Applets, as Applets
went way further than Java WebStart ever did.</div>
<div style="font-family:monospace"><br>
</div>
<div style="font-family:monospace">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 <b><i><u>their mere existence</u></i></b> 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.</div>
<div style="font-family:monospace"><br>
</div>
<div style="font-family:monospace">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.</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri, Oct 31, 2025 at
2:35 PM Mark Yagnatinsky <<a href="mailto:markyag@gmail.com" target="_blank">markyag@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div dir="ltr">In the olden days, it was pretty common
to make apps that supported two launch modes:
<div>1. entry point in main() created its own window
using JFrame or whatever.</div>
<div>2. But also extend Applet so as to run in the
browser.</div>
<div><br>
</div>
<div>These days, the second mode no longer works
because no browser supports applets.</div>
<div>But the first mode still works fine. It would
STOP working if the applet API were removed.</div>
<div>(In particular, class loading would fail if the
JVM can't find the parent class.)</div>
<div><br>
</div>
<div>Normally, when we talk about removing APIs, there
is a simple bit of messaging that goes something
like this:</div>
<div>1. This is hopefully a simple code change (e.g.,
stop extending Applet, since it does you no good
anyway).</div>
<div>2. If you're not ready to make the code change,
stay on an old version for now</div>
<div>3. If you're not going to be ready soon, use an
LTS release.</div>
<div><br>
</div>
<div>There's a cluster of vague implicit assumptions
buried in such messaging, such as:</div>
<div>1. The application is actively maintained, or at
least there exists a person or group of people
nominally in charge of maintaining it.</div>
<div>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.</div>
<div>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.</div>
<div><br>
</div>
<div>In the case of the applet API, this is all
largely false.</div>
<div>There are people who once upon a time put a cute
little applet on the web, and also made it runnable
standalone.</div>
<div>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.</div>
<div>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.</div>
<div><br>
</div>
<div>But even though these are all unmaintained, it
does not mean they are unused!</div>
<div>They may indeed have users, possibly users who
find them indispensable!</div>
<div>But those users may not have access to the code,
and may not be programmers even if they did have
access.</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div>(Not everyone knows how to set up a VM and an
emulator and stuff.)</div>
<div>Also, some people may be too nervous to run an
old JVM that hasn't gotten security updates in a
long time.</div>
<div><br>
</div>
<div>Conversely, consider the cost of keeping these
APIs. They would still be deprecated.</div>
<div>Nobody is filing bug reports against them, since
they are unusable anyway.</div>
<div>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.</div>
<div><br>
</div>
<div>Thoughts?</div>
<div><br>
</div>
<div>Thanks,</div>
<div>Mark.</div>
</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
<br>
</div>
</blockquote></div></div>