<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi Sean,<br>
<br>
Looks good.<br>
<br>
I would quibble with System.java:335-6<br>
<pre><span class="changed">"Java virtual machine does</span> <span class="changed">not allow a security manager"
</span></pre>
I would say only "a security manager is not allowed to be set
dynamically."<br>
<br>
There is no need to identify the Java virtual machine. The VM
itself has nothing to do with it.<br>
Also remove the same phrase in SecurityManager class javadoc.<br>
<br>
Regards, Roger<br>
<br>
<br>
<div class="moz-cite-prefix">On 9/13/18 4:02 PM, Sean Mullan wrote:<br>
</div>
<blockquote type="cite"
cite="mid:4c0ddbab-facb-0a57-b5b9-56490ebb4882@oracle.com">This is
a SecurityManager related change which warrants some additional
details for its motivation.
<br>
<br>
The current System.setSecurityManager() API allows a
SecurityManager to be set at run-time. However, because of this
mutability, it incurs a performance overhead even for applications
that never call it and do not enable a SecurityManager
dynamically, which is probably the majority of applications.
<br>
<br>
For example, there are lots of "SecurityManager sm =
System.getSecurityManager(); if (sm != null) ..." checks in the
JDK. If it was known that a SecurityManager could never be set at
run-time, these checks could be optimized using constant-folding.
<br>
<br>
There are essentially two main parts to this change:
<br>
<br>
1. Deprecation of System.securityManager()
<br>
<br>
Going forward, we want to discourage applications from calling
System.setSecurityManager(). Instead they should enable a
SecurityManager using the java.security.manager system property on
the command-line.
<br>
<br>
2. A new JDK-specific system property to disallow the setting of
the security manager at run-time: jdk.allowSecurityManager
<br>
<br>
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.
<br>
<br>
webrev:
<a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~mullan/webrevs/8191053/webrev.00/">http://cr.openjdk.java.net/~mullan/webrevs/8191053/webrev.00/</a>
<br>
CSR: <a class="moz-txt-link-freetext" href="https://bugs.openjdk.java.net/browse/JDK-8203316">https://bugs.openjdk.java.net/browse/JDK-8203316</a>
<br>
JBS: <a class="moz-txt-link-freetext" href="https://bugs.openjdk.java.net/browse/JDK-8191053">https://bugs.openjdk.java.net/browse/JDK-8191053</a>
<br>
<br>
(I will likely also send this to core-libs for additional review
later)
<br>
<br>
--Sean
<br>
</blockquote>
<br>
</body>
</html>