New candidate JEP: 411: Deprecate the Security Manager for Removal

[Peter Firmstone]

Which version of Java is this planned for?   Will the last version 
supporting the security manager be a long term support version, eg back 
ports of security patches and TLS technologies?

We have our own security manager implementation and policy provider 
implementations.  Both of these are high performance and non-blocking 
and we are able to dynamically grant and revoke some permissions.   
While I acknowledge the Java policy implementation has a significant 
performance impact, due to blocking permission checks, ours is less than 
1%.  Our software doesn't share PermissionCollection instances among 
threads, or even have a Permissions cache, PermissionCollection's are 
generated for each permission check and discarded for garbage 
collection, the Permission object themselves are cached (after 
initialization and safe publication), as are the results of repeated 
permission checks.  We also have our own Permission implementations.

We have tools that generate policy files with least privilege, although 
we will manually alter them with wildcards, for network connections for 
instance.

In our software, dynamic permissions are granted after authentication of 
TLS connections.

It is too early for me to tell if there are suitable replacement 
technologies available.  I can understand the motivation for reducing 
Java's software development burden, but I think this version of Java 
might be the last for us, it would certainly be good if a long term 
support version was available, perhaps indefinitely lol.

Regards,
  
Peter Firmstone
Zeus Project Services Pty Ltd.


On 16/04/2021 4:05 am, mark.reinhold at oracle.com wrote:
> https://openjdk.java.net/jeps/411
>
>    Summary: Deprecate the Security Manager for removal in a future
>    release. The Security Manager dates from Java 1.0. It has not been the
>    primary means of securing client-side Java code for many years, and it
>    has rarely been used to secure server-side code. To move Java forward,
>    we intend to deprecate the Security Manager for removal in concert with
>    the legacy Applet API (JEP 398).
>
> - Mark