Fwd: new hurdle for applications which programatically install a SecurityManager

Sean Mullan sean.mullan at oracle.com
Thu Nov 18 19:21:37 UTC 2021



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




More information about the security-dev mailing list