RFR (12): 8191053: Provide a mechanism to make system's security manager immutable

[Peter]

Hi Alan,

I'm a little time poor presently, but will put it on my todo list.  
Admittedly this is one part of the JVM that could have better test 
coverage.   Implementing a custom SecurityManager was fraught with 
recursion difficulties, I documented the pitfalls in our code.

Anyone who's using a custom security manager with Java 8, will now be 
using System.setSecurityManager() instead of the command line option due 
to this bug, I don't think it's publicly documented, it's probably fine 
to deprecate System.setSecurityManager(), but not to remove at this 
time.  Ironically we converted to the command line option with Java 6.  
I understand the need to make the SecurityManager reference immutable.

Incidentally, our SecurityManager implementation is dynamic, it can 
grant and remove permissions, provided they haven't been allowed to 
escape the guards control, but it's also concurrent and high scaling, 
mostly because we do a lot of network calls, which invoke a lot of 
security checks.  We also have a custom cache-less policy provider 
that's high scaling using immutability, thread confinement and garbage 
collection, it also orders permission checks for best performance.   The 
sun policy provider performs poorly mostly due to it's blocking cache, 
loosing the cache makes a big performance improvement.

Regards,

Peter.

On 18/09/2018 5:39 PM, Alan Bateman wrote:
> On 17/09/2018 13:41, Peter Firmstone wrote:
>> Has the attached regression been fixed "Re: 
>> -Djava.security.manager=problems for service provider"?   I recently 
>> changed all our code to use System.setSecurityManager(), because of 
>> this regression, prior to that we used the command line option, it's 
>> going to take some time to revert...
> I think it would be better to start a new thread with a test case that 
> demonstrates the issue with JDK 11 builds. As I think I noted in the 
> original discussion (from March) there were several issues with 
> recursive initialization and handling of resources that have been 
> fixed in recent releases. I can't say if they address the the specific 
> issue you were running into with JDK 8 but it would be useful to know 
> if there is still an issue or not.
>
> -Alan