The proposal that removed applets from Java needed only one sentence of justification. "There is no reason to keep the unused and unusable Applet API," reads JEP 504, which removed the feature from Java 26 in March 2026. The odd part is how long it took before anyone could write that sentence.
Applets were small Java programs that ran inside web pages through a browser add-on called a plugin. Chrome switched those plugins off by default in April 2015, and Firefox dropped Java support in March 2017. After that, applets had almost nowhere left to run. Yet for most of another decade, every copy of Java still shipped with the Applet API, the building blocks programmers used to write them.
Java's maintainers took the applet system apart in stages. In 2017 they marked the API deprecated, which in Java means "please stop using this" with no promise of removal. In 2018 they deleted the machinery that actually ran applets: the browser plugin, a launcher called Java Web Start, and the standalone applet viewer. In 2021 the API was formally scheduled for removal. Java 24 then switched off the Security Manager, the sandbox applets had lived inside. Only then did the API itself go.
So the house came down in 2018, and its front door stood by itself for eight more years. Why would anyone keep a door to nowhere?
Because by then it had become part of other people's buildings. Java promises that code which works today will work tomorrow, and over three decades strangers had used applet pieces for jobs unrelated to browsers. Some desktop programs used the Applet class as an ordinary on-screen panel. Others used its AudioClip feature to play sounds, which meant Java 25 had to add a replacement before the old one could be retired. Phil Race, who led the removal, describes changing thousands of tests and combing official documentation for passing mentions of applets. All of that work falls on the maintainers, and its benefit is nearly invisible to everyone else. Under those terms, putting it off is the rational choice.
Meanwhile, one of the applet era's best ideas had already moved on.
In 1996, three Princeton researchers, Drew Dean, Edward Felten and Dan Wallach, examined Java's security and proposed something modest: a trusted "File Save" window drawn by the system rather than by the applet. The user picks a file, and the applet receives that file and nothing else on the disk. Choosing the file is itself the grant of permission. They preferred this to security pop-ups, which train people to click "yes" without reading, because it folds permission into something users are already doing.
The idea kept coming back. Java Web Start's FileOpenService, around 2001, gave restricted programs a chosen file's contents without revealing where it lived. Security researchers arrived at the same picker, calling it a "powerbox," and Apple built one into its Mac App Sandbox in 2011. Android followed in 2013, and Chrome 86 brought it to websites in October 2020 as showOpenFilePicker(), which is still a draft rather than a standard. Direct borrowing from Princeton is hard to prove in each case, but the design is the same.
Java's own version was dropped from Oracle's JDK in 2018 with the rest of Web Start, eight years before the API that almost nobody still used.
Removing an interface means accounting for everyone who built on it, so removal moves at the pace of whoever is slowest to adapt. Copying an idea requires nobody's consent. Today, when you pick a photo to upload, a window you barely notice decides exactly which file a program may see. That is what those three researchers were after in 1996.