-
Sub-task
-
Resolution: Delivered
-
P4
-
24
As of JDK 24, the Security Manager is permanently disabled. This means that:
- You cannot enable a Security Manager at startup with `java -Djava.security.manager ...`. Attempting to do so causes the JVM to report an error and exit.
- You cannot install a custom Security Manager during run time by calling `System::setSecurityManager`. Attempting to do so causes the JVM to throw an `UnsupportedOperationException`.
- Methods in the Java Platform API that were previously specified to throw `SecurityException` if denied permission by a Security Manager have been changed to not throw `SecurityException`.
- The system policy file, `$JAVA_HOME/conf/security/java.policy`, has been removed.
- Several system properties and security properties related to the Security Manager are ignored.
See [JEP 486](https://openjdk.org/jeps/486#Description) for more information. Applications depending on the Security Manager should consider alternatives, such as containers.
In addition, methods in the Security Manager API have been degraded to either return `null` or `false`, pass through the caller's request, or unconditionally throw a `SecurityException` or `UnsupportedOperationException`. The full set of behavioral changes is available [here](https://bugs.openjdk.org/browse/JDK-8338412). Most libraries that use the Security Manager API to check permissions or execute privileged operations will behave in the same way on JDK 24 as they did on JDK 23 when a Security Manager was not enabled. However, some libraries may be affected by the following incompatible changes in JDK 24:
- `AccessController::checkPermission` always throws `AccessControlException`.
- `Policy::setPolicy` always throws `UnsupportedOperationException`.
- `SecurityManager::check*` methods always throw `SecurityException`.
- `Subject::getSubject` always throws `UnsupportedOperationException`. Code using this method should instead use the replacement API `Subject::current` which was introduced in JDK 18.
See [the advice to library developers](https://openjdk.org/jeps/486#Advice-to-maintainers-of-libraries-that-support-the-Security-Manager) for more information.
- You cannot enable a Security Manager at startup with `java -Djava.security.manager ...`. Attempting to do so causes the JVM to report an error and exit.
- You cannot install a custom Security Manager during run time by calling `System::setSecurityManager`. Attempting to do so causes the JVM to throw an `UnsupportedOperationException`.
- Methods in the Java Platform API that were previously specified to throw `SecurityException` if denied permission by a Security Manager have been changed to not throw `SecurityException`.
- The system policy file, `$JAVA_HOME/conf/security/java.policy`, has been removed.
- Several system properties and security properties related to the Security Manager are ignored.
See [JEP 486](https://openjdk.org/jeps/486#Description) for more information. Applications depending on the Security Manager should consider alternatives, such as containers.
In addition, methods in the Security Manager API have been degraded to either return `null` or `false`, pass through the caller's request, or unconditionally throw a `SecurityException` or `UnsupportedOperationException`. The full set of behavioral changes is available [here](https://bugs.openjdk.org/browse/JDK-8338412). Most libraries that use the Security Manager API to check permissions or execute privileged operations will behave in the same way on JDK 24 as they did on JDK 23 when a Security Manager was not enabled. However, some libraries may be affected by the following incompatible changes in JDK 24:
- `AccessController::checkPermission` always throws `AccessControlException`.
- `Policy::setPolicy` always throws `UnsupportedOperationException`.
- `SecurityManager::check*` methods always throw `SecurityException`.
- `Subject::getSubject` always throws `UnsupportedOperationException`. Code using this method should instead use the replacement API `Subject::current` which was introduced in JDK 18.
See [the advice to library developers](https://openjdk.org/jeps/486#Advice-to-maintainers-of-libraries-that-support-the-Security-Manager) for more information.