On 13/05/2021 10:59 pm, Sean Mullan wrote:
The JEP does have a section on this:
"In future JDK releases, we may degrade the Security Manager APIs so
that they remain in place but have 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 would allow libraries that support the Security
Manager and were compiled against previous Java releases to continue
to work without change or even recompilation. Once the compatibility
risk has declined to an acceptable level, we expect to remove the APIs."
So, if the JEP is targeted to 17, then the Security Manager will be
deprecated for removal but will still be fully functional and
supported in 17.
*Disclaimer: The next part is forward thinking, and subject to change.*
Once we start degrading the APIs, the functionality of the Security
Manager may not fully work as before, so in that sense you might
consider it "removed". We don't yet have a definitive timeline for
that, it may occur in the next release, or it may not, but it will
probably occur within a few releases after the release it is targeted to.
--Sean
It will be important for existing JAAS login mechanisms and
AccessControlContext's for Subject's are still functional and preserved
so that TLS clients and servers can authenticate. The
AccessControlContext would only need to contain an array with only one
ProtectionDomain, containing the Subject.
--
Regards,
Peter Firmstone
Zeus Project Services Pty Ltd.