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. >
