Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News The End of Applets

The End of Applets

This item in japanese

Lire ce contenu en français

Oracle is set to mark Applet APIs for removal in JEP-398. The demarcation follows multiple years of deprecation notices (JEP-289) after all major browsers have removed support for the NPAPI plugin that powered Java Applets since the last millennium.

Java Applets originally powered Rich Internet Applications at a time when browsers had less power and fewer standards for developing applications. The capability for enabling Java applets was powered by the Netscape Plugin Application Programming Interface (NPAPI) to run sandboxed Java applications in the browser. NPAPI first appeared in browsers in 1995, long before the incorporation of Mozilla (2005) and the first release of Chrome (2008).

Prior to modern browser standards, these applets were often used for activities like file transfers, authentication, and various other cases that JavaScript was unable to handle. Browsers began removing support for NPAPI in 2015 to simplify maintenance, operating in tandem with Oracle’s published whitepaper, "Migrating from Java Applets to plugin-free Java technologies."

Although security had been a topic of interest related to Java applets prior to the 2015 API changes, many organizations were able to defend clients through management tools like Deployment Rule Sets or locking Java/browser compatibility together in an isolated Citrix environment.

While previous Java versions have marked Java applets as deprecated, the APIs were left in place to avoid compilation or runtime issues with applications that leveraged the APIs in some way even without not using the applet functionality. This feature, marking items as deprecated and delaying removal, was standard in Java and OpenJDK for about the first 20 years of the platform.

InfoQ spoke with Dr. Deprecator, alter-ego of OpenJDK contributor Stuart Marks about how the OpenJDK project uses the @Deprecated tag to communicate and what has been deprecated.

Java 9 enhanced the @Deprecated annotation to add an attribute called forRemoval. Following the change in JEP-398, applet APIs will have the forRemoval=true attribute set, causing compilers and tools to emit stronger warnings before the APIs get actually removed. The passage through multiple warning gates helps avoid community code disruption, in line with language architect Brian Goetz' 2015 presentation, "Move Deliberately and Don't Break Anything."

Other items that have been removed from the core Java APIs are:

Users curious to see if this change will affect their application or any dependencies can leverage a combination of two tools on their code and its dependencies:

  • jdeps, a tool that analyzes use compatibility-endangering APIs. This can help a team understand if they use any non-spec APIs that are subject to change.
  • jdeprscan, a utility for an analyzing code against the deprecation annotations to understand how it will be at risk if it does not adjust to the pending deprecation.

When asked if deprecation could be applied to Serialization, the applet-oriented SecurityManager, and other aspects, Deprecator replied simply, "Hold my beer," to indicate that change could be in the works.

Rate this Article