The OpenJDK project has proposed JEP-411 as a means of deprecating the SecurityManager. If accepted, this would be the first step in a multi-year process in which the OpenJDK Quality Outreach Campaign can guide affected projects towards alternatives before anything is removed.
Voting on the JEP is yet to occur and deprecation does not mean immediate removal. An affirmative vote would start the deprecation process and any future removal would not retroactively impact prior Java versions. The drive to remove the SecurityManager follows the recent phase (2021) of the applet deprecation process (2017) that has been in progress for several years (2016). JEP-411 provides an explanation for the deprecation:
"The Security Manager dates from Java 1.0. It has not been the primary means of securing client-side Java code for many years, and it has rarely been used to secure server-side code. To move Java forward, we intend to deprecate the Security Manager for removal in concert with the legacy Applet API (JEP 398)."
The original SecurityManager was designed in 1996 as a defense against portable code running on a client PC. The availability of applets was designed within Netscape Navigator's NPAPI (Netscape Plugin API) to add features that were not present in early versions of JavaScript.
Usage of the SecurityManager does occur outside of applets and several affected projects have been identified. Some have spoken out in support of JEP-411. InfoQ spoke with Arjan Tijms, security lead for Jakarta EE, about recent discussion on the Jakarta mailing list.
Now I've personally been arguing for not using/depending on the security manager in server side code for a long time. The idea of running potentially untrusted code on your own server always struck me as awkward and something you would not do anyway, even when running multiple applications on a single server instance was still somewhat of a thing.
-Arjan Tijms, security lead for Jakarta EE
A lengthy Reddit thread cited Tijms’ prior comments from 2014 in Omnifaces, saying, "The Java SE security manager is used for code level protection, which is a level of protection that is rarely if ever needed in Java EE as it's extremely rare that a server will run untrusted code (like e.g. a browser which runs an untrusted Applet from the Internet)."
Jim Manico, author of Iron Clad Java, agrees stating, "I have literally never used the [SecurityManager] in enterprise development."
Projects that are using the SecurityManager can engage the OpenJDK projects through various channels. Uwe Schindler, project lead for Apache Lucene, has identified Apache Solr and ElasticSearch/OpenSearch as affected projects. The non-Applet use cases of these projects includes the ability for plugins to read information without impacting the host. Other projects include Apache NetBeans, which uses the SecurityManager for monitoring rather than security. Monitoring capabilities have migrated to JDK Flight Recorder and third party systems like Contrast Community Edition.
With discussions ongoing, even a vote in favor of deprecation will offer ample time for affected parties to identify alternatives.
