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
