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

[Alan Bateman]

On 14/09/2018 14:28, David Lloyd wrote:
> :
> I can say that this explanation would be more palatable by far if the
> security manager as a whole could be deprecated all at once.  I for
> one would certainly be happy to remove support for it in the software
> that I maintain (it's a considerable amount of code and other
> gymnastics to be sure).  However, I'm not sure that our users and
> customers will be so easily convinced.  My understanding is that there
> are plenty of corporate and perhaps government security standards that
> dictate security manager usage.
>
> If the security manager itself is not yet to be deprecated, then I
> have a much harder time accepting this argument.  It's not really a
> stepping stone in any practical sense, at least not from our
> perspective, unless that step is "break JBoss first, and then break
> everyone else later"; to be fair though I'm approximately 200% more
> cynical in the morning. :)
If the proposed patch goes into jdk/jdk then it just means that code 
using System.setSecurityManager gets a deprecation warning at 
compile-time, nothing more. I agree it would be nice to able to go 
further and deprecate SecurityManager, also emit a warning if 
-Djava.security.manager is set on the command line. These seem like 
possible future disruptive steps in a multi-release plan.

-Alan