On Sat, 18 Dec 2021 00:40:05 GMT, David Holmes <dhol...@openjdk.org> wrote:
> I think specifying "allow" would be the behaviour preserving change here. This is strictly true. I did think about doing this. However, I don't think it makes much of a practical difference. It's always been fully supported to enable the security manager using properties, and the rmiregistry main hardly does anything before enabling the security manager. As long as we're going to the trouble of setting a property to _allow_ the security manager, might as well _enable_ it at the same time, I think. In addition, the warning messages emitted by enabling the security manager with the API are worse than those from the command line. Using the API gives this: WARNING: A terminally deprecated method in java.lang.System has been called WARNING: System::setSecurityManager has been called by sun.rmi.registry.RegistryImpl WARNING: Please consider reporting this to the maintainers of sun.rmi.registry.RegistryImpl WARNING: System::setSecurityManager will be removed in a future release and using the property gives this: WARNING: A command line option has enabled the Security Manager WARNING: The Security Manager is deprecated and will be removed in a future release Using the property gives a shorter warning and one that is less misleading (!) than the one from use of the API. (I mean, it's kind of ridiculous for the `rmiregistry` command to emit a message suggesting that something be reported to the maintainers of `RegistryImpl`. In some sense it would be good if there were a way to disable the warning, but I rate the likelihood of that occurring as low.) ------------- PR: https://git.openjdk.java.net/jdk18/pull/45
