On 9/13/18 4:50 PM, Stuart Marks wrote:
Hi Sean,
Looks sensible to me.
On 9/13/18 1:02 PM, Sean Mullan wrote:
2. A new JDK-specific system property to disallow the setting of the
security manager at run-time: jdk.allowSecurityManager
If set to false, it allows the run-time to optimize the code and
improve performance when it is known that an application will never
run with a SecurityManager. To support this behavior, the
System.setSecurityManager() API has been updated such that it can
throw an UnsupportedOperationException if it does not allow a
security manager to be set dynamically.
I guess the default value is true?
The behavior makes sense, though the name I think is misleading. It
seems not to disallow a security manager, but to disallow the
capability to *set* the security manager. Maybe
"jdk.allowSetSecurityManager" ?
When -Djdk.allowSecurityManager is set at startup, no security manager
is allowed. Most cases a security manager is started via
-Djava.security.manager on the command-line.
This name also prepares for the future to potentially flip the default
(no security manager by default) and allow a security manager at runtime.
Mandy
