On 11/18/21 1:22 PM, Rick Hillegas wrote:
Here's the output I get when I run that program against 18-ea+23-1525 WITHOUT setting java.security.manager on the boot command line: Exception in thread "main" java.lang.UnsupportedOperationException: The Security Manager is deprecated and will be removed in a future release at java.base/java.lang.System.setSecurityManager(System.java:411) at DERBY_7126_B.main(DERBY_7126_B.java:34) Here's the output I get when I run that program against 18-ea+23-1525 but do set java.security.manager on the boot command line: WARNING: A terminally deprecated method in java.lang.System has been called WARNING: System::setSecurityManager has been called by DERBY_7126_B (file:/Users/rhillegas/src/) WARNING: Please consider reporting this to the maintainers of DERBY_7126_B WARNING: System::setSecurityManager will be removed in a future release Is this asymmetry in the handling of this new system property deliberate?
Yes. The system property is read early (and never again) in VM init phase 3.
If so, what is the motivation for this asymmetry?
One of the motivations is to improve the performance of applications that do not use the Security Manager. These applications ideally should not have to incur the cost of supporting a SecurityManager if it is not used. By reading the system property early, the code for loading and checking the security field can be removed. More details are in the CSR for this change that initially went into JDK 12: https://bugs.openjdk.java.net/browse/JDK-8203316
If not, can the new property be made to operate like the other SecurityManager properties, that is, can the JDK be amended so that java.security.manager can be set programatically?
AFAIK, the "java.security.manager" system property has always been read early before the main application is launched. Also, a change like that would negate the performance benefits described above.
--Sean
