new hurdle for applications which programatically install a SecurityManager

[Richard Hillegas]

Build 18-ea+23-1525 has introduced another hurdle for applications which 
use the SecurityManager. In order to install a SecurityManager, you now 
have to set -Djava.security.manager=allow on the boot command line. This 
property cannot be set programatically, unlike the other system 
properties related to the SecurityManager. I have attached a simple 
repro of this asymmetry (DERBY_7126_B) to 
https://issues.apache.org/jira/browse/DERBY-7126. The repro 
programatically sets java.security.manager. Here's the code:

import java.io.PrintWriter;
import java.util.Properties;
/**
 * Demonstrate that the SecurityManager can be installed by setting
 */
@SuppressWarnings("removal")
public class DERBY_7126_B
{
    private static final String PROPERTY_FILE_NAME = 
"/tmp/derby-7126_B.properties";
    private static final String SECURITY_POLICY_FILE_NAME = 
"/tmp/derby-7126_B.policy";
    private static final String SECURITY_POLICY_FILE_URL = "file:" + 
SECURITY_POLICY_FILE_NAME;

    private final static String POLICY_FILE_PROPERTY = 
"java.security.policy";

    private static final String SECURITY_FILE_CONTENTS =
        "grant\n" +
        "{\n" +
        "  permission java.io.FilePermission \"/tmp/-\", 
\"read,write,delete\";\n" +
        "};\n"
        ;

    public static void main(String... args) throws Exception
    {
        // write the policy file
        try (PrintWriter pw = new PrintWriter(SECURITY_POLICY_FILE_NAME))
        { pw.write(SECURITY_FILE_CONTENTS); }

        // start up a security manager using the policy file we just wrote
        System.setProperty( POLICY_FILE_PROPERTY, 
SECURITY_POLICY_FILE_URL );
        System.setProperty( "java.security.manager", "allow" );

        System.setSecurityManager( new SecurityManager() );
    }

}

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? If so, what is the motivation for this asymmetry? 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?

Thanks,
-Rick