Summary

Update supported JDK versions prior to JDK 12 to ignore the "allow" and "disallow" options of the java.security.manager system property (if set on the java command line) instead of treating them as classnames.

Problem

In JDK 12, we introduced two new token options for the java.security.manager system property ("allow" and "disallow").

Many applications/frameworks are designed to run on multiple JDKs and for those that enable the SecurityManager at runtime via System.setSecurityManager they have to specify the "allow" option as of JDK 18 (see https://bugs.openjdk.org/browse/JDK-8203316). However, these applications would also prefer to use the same command line across multiple versions of the JDK, especially if it is not known what JDK version a user will use.

But on JDK versions earlier than JDK 12, if these options are specified, the runtime attempts to load a SecurityManager implementation with the classname of "allow" or "disallow", which results in an Error and the application will not start up.

Some applications have worked around this by creating a custom SecurityManager named "allow" that once enabled, immediately uninstalls itself, but this workaround is awkward and should not be necessary.

Solution

If the java.security.manager system property is set to "allow" or "disallow" on the java command line, silently ignore it.

Specification

No specification changes, just a behavior change.