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
