Hello Scott,
On 4/25/22 2:25 PM, Scott Stark wrote:
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.
Can you clarify what you mean by "a migration feature" and also provide
some background as to why vendors in EEPD would like to see this? Do you
mean something like a system property that enables the degraded behavior
as described above?
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.
So, first we do not yet have a proposed target date for when we would
like to remove support for the Security Manager (SM) from the JDK. By
removing support, I mean that the JDK would no longer include a SM
implementation. However, I don't anticipate that any SM specific APIs
would be degraded *prior* to removing SM support from the JDK.
Some APIs will likely be degraded as described above at the same time we
remove support for the SM from the JDK.
As for when the APIs will actually be removed, this will most likely be
a longer period, possibly several JDK releases. We recognize that many
libraries and applications will need time to adapt to the changes and
remove dependencies on the APIs. We have tools that check open source
repositories for API dependencies and are able to provide us with data
that helps assess the compatibility risk. However, I can't give you a
timeframe for API removal yet.
HTH,
Sean
