<div><br></div><div dir="auto">Also, from the point of view of Apache NetBeans, here’s a list of our concerns with these developments:</div><div dir="auto"><br></div><div dir="auto"><div><a href="https://blogs.apache.org/netbeans/entry/jep-411-deprecate-the-security">https://blogs.apache.org/netbeans/entry/jep-411-deprecate-the-security</a></div></div><div dir="auto"><p style="font-family:"Helvetica Neue","Lucida Grande",Helvetica,Arial,Verdana,sans-serif;color:rgb(34,34,34)" dir="auto">Apache NetBeans doesn't use java.lang.SecurityManager to guarantee security, but rather to gain additional insight into the JVM's behavior. Without having such insights, the IDE's user experience would be severely affected.</p><p style="font-family:"Helvetica Neue","Lucida Grande",Helvetica,Arial,Verdana,sans-serif;color:rgb(34,34,34)" dir="auto">Are replacement APIs being designed and will they be provided for evaluation before JEP-411 is integrated?</p></div><div dir="auto">Thanks,</div><div dir="auto"><br></div><div dir="auto">Gj</div><div dir="auto"><br></div><div dir="auto"><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Thu, 29 Apr 2021 at 07:38, Peter Firmstone <<a href="mailto:peter.firmstone@zeus.net.au">peter.firmstone@zeus.net.au</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">Which version of Java is this planned for?   Will the last version <br>
supporting the security manager be a long term support version, eg back <br>
ports of security patches and TLS technologies?<br>
<br>
We have our own security manager implementation and policy provider <br>
implementations.  Both of these are high performance and non-blocking <br>
and we are able to dynamically grant and revoke some permissions.   <br>
While I acknowledge the Java policy implementation has a significant <br>
performance impact, due to blocking permission checks, ours is less than <br>
1%.  Our software doesn't share PermissionCollection instances among <br>
threads, or even have a Permissions cache, PermissionCollection's are <br>
generated for each permission check and discarded for garbage <br>
collection, the Permission object themselves are cached (after <br>
initialization and safe publication), as are the results of repeated <br>
permission checks.  We also have our own Permission implementations.<br>
<br>
We have tools that generate policy files with least privilege, although <br>
we will manually alter them with wildcards, for network connections for <br>
instance.<br>
<br>
In our software, dynamic permissions are granted after authentication of <br>
TLS connections.<br>
<br>
It is too early for me to tell if there are suitable replacement <br>
technologies available.  I can understand the motivation for reducing <br>
Java's software development burden, but I think this version of Java <br>
might be the last for us, it would certainly be good if a long term <br>
support version was available, perhaps indefinitely lol.<br>
<br>
Regards,<br>
<br>
Peter Firmstone<br>
Zeus Project Services Pty Ltd.<br>
<br>
<br>
On 16/04/2021 4:05 am, <a href="mailto:mark.reinhold@oracle.com" target="_blank">mark.reinhold@oracle.com</a> wrote:<br>
> <a href="https://openjdk.java.net/jeps/411" rel="noreferrer" target="_blank">https://openjdk.java.net/jeps/411</a><br>
><br>
>    Summary: Deprecate the Security Manager for removal in a future<br>
>    release. The Security Manager dates from Java 1.0. It has not been the<br>
>    primary means of securing client-side Java code for many years, and it<br>
>    has rarely been used to secure server-side code. To move Java forward,<br>
>    we intend to deprecate the Security Manager for removal in concert with<br>
>    the legacy Applet API (JEP 398).<br>
><br>
> - Mark<br>
<br>
</blockquote></div></div>