Speaking with TFiR, Simon Ritter of Azul explained why JDK 26‘s Applet API removal makes perfect sense for a platform that has fully embraced cloud-native, server-side enterprise computing and why teams still running applets face serious security vulnerabilities.

WHY ARE APPLETS BEING REMOVED AFTER 30 YEARS?

Applets were the technology that made Java famous when it launched in 1995, enabling interactive content in web browsers through a plugin architecture. However, applets never sustained relevance beyond the initial hype, with Java finding its true success on the server side rather than in desktop browsers. Browser plugin support was discontinued in JDK 11, and modern browsers no longer support applets even with legacy configurations.

“Applets are never going to get used in the cloud. This is all about very, very old code. It makes perfect sense to remove the Applet API because nobody in their right mind is going to try to write an applet using JDK 26. Nobody in their right mind would have used the Applet API after JDK 11.”

The removal completes a deprecation process that began when browser plugins were eliminated, cleaning up legacy code that serves no purpose in modern Java development focused on microservices, containerized applications, and cloud-native architectures.

Security Risks of Running Legacy Applets

Teams still running applets are operating on dangerously outdated JDK versions—typically JDK 6, 7, or 8—because those are the last releases with applet runtime support. These legacy environments lack modern security patches and face known vulnerabilities that cannot be addressed without upgrading to newer JDK versions that don’t support applets.

“There are still plenty of people out there who are running applets, but they run them on older versions of the JDK. They would still be using JDK 8, or maybe JDK 7, or even JDK 6, because those still have the ability to run those applets. The problem is that applets need to run through a browser, typically, and that’s the way most people have used them in the past. But even the oldest browser, like Internet Explorer, no longer has support, so you can’t get security updates for it, which means it will no longer allow you to use applets through the browser plugin.”

This creates a compounding security problem: legacy JDK versions without current patches running in legacy browsers without security updates, exposing organizations to exploitable vulnerabilities.

Java’s Evolution From Desktop to Server-Side Dominance

The Applet API removal reflects Java’s complete transformation from its 1995 desktop browser origins to its current identity as the dominant platform for server-side enterprise computing, cloud-native applications, and containerized microservices.

“Applets were the thing that really made Java famous back in 1995, when it was first launched. They’ve never really been popular after the first few years. Java has very much succeeded on the server side, not on the desktop. Everybody uses JavaScript, CSS, and that kind of thing.”

Web development moved to JavaScript-based technologies, while Java found massive success in backend systems, distributed architectures, and enterprise infrastructure—use cases that have nothing to do with browser applets.

Legacy Code Cleanup and Cloud-Native Commitment

Removing the Applet API represents more than just deprecating unused functionality—it signals Java’s commitment to focusing platform development on cloud-native workloads, microservices architectures, and containerized deployments rather than maintaining compatibility with desktop technologies that no longer align with the platform’s core use cases.

“You’re really running on a very old system, which you should be looking to move away from, if you possibly can, because there are issues of security and potential vulnerabilities that could be exploited there. So it makes perfect sense to remove the Applet API at this point.”

This legacy cleanup allows JVM engineers to optimize for modern deployment patterns without the constraint of maintaining backward compatibility with browser-based desktop applications that represent a fundamentally different architectural paradigm.

Broader Context: JDK 26’s Performance and Cloud-Native Focus

In this TFiR interview, Simon Ritter explained how JDK 26’s broader feature set—including g1 garbage collector optimization, HTTP/3 API support, and Project Loom components—reflects Java’s evolution toward high-performance cloud-native computing. The Applet API removal fits within this larger narrative of shedding desktop-era legacy code to focus entirely on server-side, containerized, and distributed system use cases.

The removal also sends a clear message to enterprise teams: Java’s future is cloud-first, and maintaining compatibility with 30-year-old desktop technologies would only slow the platform’s evolution toward modern architectural patterns.

Watch the full TFiR interview with Simon Ritter here.