<html><body><div dir="ltr">
By "migration feature" I'm talking about being able to retain the type of library code where one has a conditional call to an AccessController::doPrivileged(...) method that is only done when System.getSecurityManager() is not null. Not having to remove this code in all dependent libraries for a given Jakarta EE application server product in order to run on Java SE 21 is seen as necessary to navigate supporting application servers over a range of Java SE versions. The general consensus was that having to deal with Java SE 11, 17 and 21 would only be possible if this SecurityManager related code could remain as is, even if the only executed path would be for System.getSecurityManager() == null. We can deal with a gradual degradation of the SecurityManager behavior, but it was unclear if Java SE 21 was looking for a complete removal of the APIs the libraries use.</div><div dir="ltr"><br></div><div dir="ltr">I'm sure many of the Jakarta EE platform dev members have code repositories to offer for scanning to aide in determining when the SecurityManager dependencies have been removed. If there is a avenue for that information, please let me know.</div><div dir="ltr"><br></div><div dir="ltr">Thanks,</div><div dir="ltr">Scott<br><br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Apr 26, 2022 at 11:09:22 AM, Sean Mullan <<a href="mailto:sean.mullan@oracle.com">sean.mullan@oracle.com</a>> wrote:<br></div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" type="cite">
<div>
<div>
Hello Scott,<br><br>On 4/25/22 2:25 PM, Scott Stark wrote:<br><blockquote type="cite"> Hello,<br></blockquote><blockquote type="cite"> <br></blockquote><blockquote type="cite"> I'm Scott Stark of Red Hat, and a member of the Jakarta EE platform dev <br></blockquote><blockquote type="cite"> group (EEPD). I'm currently coordinating the Jakarta EE 10 release that <br></blockquote><blockquote type="cite"> is targeting June of this year (2022). The removal of the <br></blockquote><blockquote type="cite"> SecurityManager as described in JEP-411 has been a topic for the EEPD on <br></blockquote><blockquote type="cite"> may calls this year. Recent discussions make it clear that any <br></blockquote><blockquote type="cite"> SecurityManager alternative would need to be taken up by the EEPD, and <br></blockquote><blockquote type="cite"> such an effort is going to be a non-trivial undertaking, and may not be <br></blockquote><blockquote type="cite"> addressed at all.<br></blockquote><blockquote type="cite"> <br></blockquote><blockquote type="cite"> A general concern among vendors in the EEPD is the timeframe for the <br></blockquote><blockquote type="cite"> code that bridges between the JVM running with and without a <br></blockquote><blockquote type="cite"> SecurityManager instance needing to be updated. Such code is the subject <br></blockquote><blockquote type="cite"> of this JEP-411 paragraph:<br></blockquote><blockquote type="cite"> <br></blockquote><blockquote type="cite"> "In feature releases after Java 18, we will degrade other Security <br></blockquote><blockquote type="cite"> Manager APIs so that they remain in place but with limited or no <br></blockquote><blockquote type="cite"> functionality. For example, we may revise AccessController::doPrivileged <br></blockquote><blockquote type="cite"> simply to run the given action, or revise System::getSecurityManager <br></blockquote><blockquote type="cite"> always to return null. This will allow libraries that support the <br></blockquote><blockquote type="cite"> Security Manager and were compiled against previous Java releases to <br></blockquote><blockquote type="cite"> continue to work without change or even recompilation. We expect to <br></blockquote><blockquote type="cite"> remove the APIs once the compatibility risk of doing so declines to an <br></blockquote><blockquote type="cite"> acceptable level."<br></blockquote><blockquote type="cite"> <br></blockquote><blockquote type="cite"> Of particular interest is the timeframe for "remove the APIs once the <br></blockquote><blockquote type="cite"> compatibility risk of doing so declines to an acceptable level".<br></blockquote><blockquote type="cite"> <br></blockquote><blockquote type="cite"> Vendors in EEPD would like to see Java SE 21 ship with a migration <br></blockquote><blockquote type="cite"> feature along the lines of the proposed "AccessController::doPrivileged <br></blockquote><blockquote type="cite"> simply to run the given action, or revise System::getSecurityManager <br></blockquote><blockquote type="cite"> always to return null" behaviors.<br></blockquote><br>Can you clarify what you mean by "a migration feature" and also provide <br>some background as to why vendors in EEPD would like to see this? Do you <br>mean something like a system property that enables the degraded behavior <br>as described above?<br><br><blockquote type="cite"> Is there some metric for tracking "when the compatibility risk of doing <br></blockquote><blockquote type="cite"> so declines to an acceptable level."? I believe the EEPD vendors would <br></blockquote><blockquote type="cite"> like readiness of their projects and upstream dependencies to somehow be <br></blockquote><blockquote type="cite"> included in any such tracking.<br></blockquote><br>So, first we do not yet have a proposed target date for when we would <br>like to remove support for the Security Manager (SM) from the JDK. By <br>removing support, I mean that the JDK would no longer include a SM <br>implementation. However, I don't anticipate that any SM specific APIs <br>would be degraded *prior* to removing SM support from the JDK.<br><br>Some APIs will likely be degraded as described above at the same time we <br>remove support for the SM from the JDK.<br><br>As for when the APIs will actually be removed, this will most likely be <br>a longer period, possibly several JDK releases. We recognize that many <br>libraries and applications will need time to adapt to the changes and <br>remove dependencies on the APIs. We have tools that check open source <br>repositories for API dependencies and are able to provide us with data <br>that helps assess the compatibility risk. However, I can't give you a <br>timeframe for API removal yet.<br><br>HTH,<br>Sean<br>
</div>
</div>
</blockquote>
</div>
</div></body></html>