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

[Sean Mullan]

On 9/14/18 2:54 PM, Bernd Eckenfels wrote:
> There is another way, by reusing the existing security manager property 
> with a new keyword („default“ is already a well known value) one could 
> implement the stable suppression of the SM without actually needing a 
> new property. It also avoids unclear meaning of denied but specified SM:
> 
> java.security.manager=disabled // or „denied“ or „forbidden“ or simply 
> „false“
> 
> This would also allow an „ignored“ (setSM does nothing).

You probably know this already, but the value of the 
java.security.manager property is a classname, and you specify that when 
you want to use your own SM implementation.

But that is probably not a big deal - we could still work around that 
and have a keyword that means as you say above with a pretty low risk of 
breaking anyone.

But as Mandy suggested, we want to work towards a point where you can 
run an app without an SM and you automatically get the optimizations 
without having to specify any property. In that case, it seems cleaner 
to have a separate property to control that behavior. Overloading the 
java.security.manager property which has been around for a really long 
time (since JDK 1.0 I think?) might end up being more confusing.

--Sean