Statement for jakartaee#460, jakartaee#406

Signed-off-by: Scott M Stark <[email protected]>
starksm64 · May 3, 2022 · 6db382f · 6db382f
1 parent 44d5f75
commit 6db382f
Showing 1 changed file with 6 additions and 0 deletions.
diff --git a/specification/src/main/asciidoc/platform/FutureDirections.adoc b/specification/src/main/asciidoc/platform/FutureDirections.adoc
@@ -25,3 +25,9 @@ for certain types of service providers called resource adapters, and the
 Jakarta Authorization specification defines requirements for
 security service providers. Future versions of this specification will
 more fully define the Jakarta EE SPI.
+
+=== SecurityManager Deprecation
+
+With the https://openjdk.java.net/jeps/411[JEP 411: Deprecate the Security Manager for Removal] initiative that has deprecated several SecurityManager related methods in Java SE 17, and further limited functionality in Java SE 18, it is clear that Jakarta EE needs to remove requirements related to the SecurityManager. Discussions with OpenJDK developers have made it clear that there will be no replacement, and conversations along the lines of maintaining similar integration points at the JDK level have confirmed that the OpenJDK team does not want to support such integration points. This leaves Jakarta EE with the option of either introducing its own specification and requirements around similar functionality, or simply removing any requirements related to the SecurityManager. Given that replacing the SecurityManager permission checks in the JDK would require bytecode enhancement of implementations, it seems unlikely that this would be an achievable effort given the low level nature of the integration, and the general lack of effectiveness of the SecurityManager model as highlighted in the JEP 411 issue.
+
+The most prudent course of action would be to announce that the SecurityManager is being deprecated in Jakarta EE10 for removal in a subsequent release, and that EE10 would be the last release with any requirements relating to the SecurityManager. Further, the rapid pace of Java SE releases brings the possibility that implementers may want to certify on EE10 and earlier releases with a Java SE version that has eliminated the SecurityManager. Existing TCK SecurityManager requirements in EE10 and earlier EE release may have to be relaxed as challenges are filed. The platform team needs to be receptive to relaxing these requirements if the need arises.