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

RE:no

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

Thanks David, will make a note of it for future reference. Cheers, Peter. On 30/04/2021 12:57 am, David Lloyd wrote: If it helps, we've solved this particular problem in a couple of places by using an MR-JAR which selects an implementation using `StackWalker` when Java 9+ is used.  I will

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

On 29/04/2021 10:57 pm, Sean Mullan wrote: On 4/29/21 1:37 AM, Peter Firmstone wrote: 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.

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

If it helps, we've solved this particular problem in a couple of places by using an MR-JAR which selects an implementation using `StackWalker` when Java 9+ is used. I will say however that it appears to be slightly less performant, which is unfortunate (but hopefully fixable at some point in the

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

On 4/29/21 2:44 AM, Geertjan Wielenga wrote: Also, from the point of view of Apache NetBeans, here’s a list of our concerns with these developments: https://blogs.apache.org/netbeans/entry/jep-411-deprecate-the-security

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

On 4/29/21 1:37 AM, Peter Firmstone wrote: 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? The JEP has not been targeted to a release yet, but the

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

We also use the SecurityManager for caller sensitive method calls. I re-implemented a secure implementation of Java Serialization, using a public API and fewer features (eg no circular links), in this implementation, each class in an object's hierarchy has its own namespace, the calling class

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

Also, from the point of view of Apache NetBeans, here’s a list of our concerns with these developments: https://blogs.apache.org/netbeans/entry/jep-411-deprecate-the-security Apache NetBeans doesn't use java.lang.SecurityManager to guarantee security, but rather to gain additional insight into

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

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

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

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

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

-bcc jdk-...@openjdk.java.net On 4/18/21 7:50 PM, David Black wrote: On Fri, 16 Apr 2021 at 04:05, > wrote: https://openjdk.java.net/jeps/411   Summary: Deprecate the Security Manager for removal in a future  

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

On Fri, 16 Apr 2021 at 04:05, 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 >

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

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.