The OpenJDK Quality Group is promoting the testing of FOSS projects with OpenJDK builds as a way to improve the overall quality of the release. This heads-up is part of a regular communication sent to the projects involved. To learn more about the program, and how-to join, please check here.

The Security Manager is a Legacy Feature with High Costs and Low Adoption

Introduced to enforce the principle of the least privilege, the Security Manager was designed to prevent unauthorized code from accessing sensitive resources like files or network connections. While effective in theory, it has fallen short in practice for several reasons:

• complexity - many developers find the Security Manager permission model cumbersome.
• limited adoption - despite its longevity, the Security Manager has seen little use in Java applications.
• maintenance overhead - the Security Manager’s least-privilege model imposes significant complexity on Java libraries. Over 1,000 methods require permission checks, and 1,200 methods must elevate privileges. Maintaining these checks consumes valuable OpenJDK contributors’ time.
• modern threat landscape - the Security Manager is poorly equipped to address contemporary security challenges, such as malicious data and serialization attacks.

Over the years, however, the Security Manager’s complexity, limited adoption, and maintenance costs have outweighed its benefits. With its deprecation in Java 17 and the near absence of community feedback, it has become clear that the Security Manager’s time has passed.

Phasing Out the Security Manager

In Java 17, the Security Manager was deprecated for removal under JEP 411. In the future, with JDK 24, its functionality will be effectively disabled. The key changes include:

• disabling the Security Manager - it will no longer be possible to enable the Security Manager at startup using command-line options, nor will it be possible to install a custom Security Manager during runtime.
• rendering the Security Manager API non-functional - the Security Manager API will remain present for compatibility but will no longer have any operational effect.
• improving maintainability - thousands of lines of code dedicated to supporting the Security Manager will be removed, freeing OpenJDK contributors to implement modern security features.

Developers and enterprises using older Java versions or legacy applications dependent on the Security Manager will retain access until JDK 24. Beyond that, they are encouraged to transition to alternative sandboxing and API interception mechanisms.

Some applications have used the Security Manager to intercept calls to the Java Platform API, such as blocking calls to System.exit. While this is not a security concern in most cases, interception remains helpful in debugging or managing application behavior. Below are a few alternative approaches that provide more reliability than the Security Manager’s interception mechanisms:

• dynamic code rewriting - tools like bytecode manipulation agents can intercept and modify behavior without relying on the Security Manager.
• static analysis - pre-deployment tools can identify and prevent undesirable API calls during the development cycle.

Taking Action

The deprecation of the Security Manager in JDK 17 had little to no impact on most Java developers. Warnings issued in JDK 17–23 generated minimal discussion in the Java ecosystem, highlighting its limited relevance. Furthermore, major frameworks and tools such as Jakarta EE, Ant, and Tomcat have already removed support for the Security Manager, reinforcing the trend.

For applications still dependent on the Security Manager, the JDK offers options to identify and address its usage:

• jdeprscan scans a JAR file for the usage of deprecated API elements, and it helps find code using these methods.
• locally and in scripts, check how you launch your Java application - with the Security Manager allowed or enabled via command line options, or policy files that require it to be installed and configured.
• messages on the console warnings highlight Security Manager usage during runtime.

These tools give code maintainers the necessary insights to transition away from the Security Manager before its complete removal in future JDK releases. By taking these steps, you can ensure a smooth transition from the Security Manager while adopting more effective security practices.

More Details

This is a summary; for more details make sure to read JEP 486.

~