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