So there's no plan to even update the JEP text to mention this stuff then? (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.)
On Mon, Nov 3, 2025 at 2:23 PM Philip Race <[email protected]> wrote: > 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. >>> >> >
