Hello, I'm Scott Stark of Red Hat, and a member of the Jakarta EE platform dev group (EEPD). I'm currently coordinating the Jakarta EE 10 release that is targeting June of this year (2022). The removal of the SecurityManager as described in JEP-411 has been a topic for the EEPD on may calls this year. Recent discussions make it clear that any SecurityManager alternative would need to be taken up by the EEPD, and such an effort is going to be a non-trivial undertaking, and may not be addressed at all.
A general concern among vendors in the EEPD is the timeframe for the code that bridges between the JVM running with and without a SecurityManager instance needing to be updated. Such code is the subject of this JEP-411 paragraph: "In feature releases after Java 18, we will degrade other Security Manager APIs so that they remain in place but with limited or no functionality. For example, we may revise AccessController::doPrivileged simply to run the given action, or revise System::getSecurityManager always to return null. This will allow libraries that support the Security Manager and were compiled against previous Java releases to continue to work without change or even recompilation. We expect to remove the APIs once the compatibility risk of doing so declines to an acceptable level." Of particular interest is the timeframe for "remove the APIs once the compatibility risk of doing so declines to an acceptable level". Vendors in EEPD would like to see Java SE 21 ship with a migration feature along the lines of the proposed "AccessController::doPrivileged simply to run the given action, or revise System::getSecurityManager always to return null" behaviors. Is there some metric for tracking "when the compatibility risk of doing so declines to an acceptable level."? I believe the EEPD vendors would like readiness of their projects and upstream dependencies to somehow be included in any such tracking. Thanks, Scott Stark
