On 9/14/18 9:28 AM, David Lloyd wrote:
The security manager is legacy these days and I think we need to figure
out a plan how to deprecate and eventually bury it. I have no idea how
many releases or years that might take but the proposal here is a
profitable first step. It's easy to imagine follow on steps where the
default changes to not support the security manager without some opt-in.
Yes, this will be disruptive for a number of usages but there is lots of
time to look for solutions to the issues that people are using the
security manager for today - for example we've seen several cases where
people set a security manager because they lack hooks to prevent plugins
from doing things (plugins or tests calling System.exit comes up
periodically for example).
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.:)
Right now we are taking a long look at the Security Manager and what its
future path should be. We started this initiative back in February with
a survey [1] to better understand how people use the Security Manager
(outside of applets and Web Start applications) and what challenges and
issues they had in using it.
In JDK 10 we removed some old methods that were not useful anymore [2].
This particular issue focuses on improving the performance of
applications that never use the Security Manager. It is the first of
potentially several enhancements in that area.
As for the future of the Security Manager, deprecating and eventually
removing it is one potential option; but there are other options we are
looking at such as simplifying it. What we really don't want to do is
continue with what we are doing today and keeping it going for what is
probably a small percentage of users. And we also don't have the
resources to enhance it to address everyone's needs. At the end of the
day it takes a lot of effort to simply maintain the JDK code to run
properly and securely under a Security Manager.
With that said, I encourage everyone to have an open mind going forward
as we request your input on different paths we may take. And keep
sending the comments. We need more use cases and data.
Thanks,
Sean
[1] https://www.surveymonkey.com/results/SM-PSJ6ZNMZ8/
[2] https://bugs.openjdk.java.net/browse/JDK-8186535
