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. 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.

Instead, we should update supported JDK versions prior to JDK 12 to simply ignore these options if they are specified.

There may be an extremely small compatibility risk that someone may have named a legitimate SecurityManager implementation "allow" or "disallow". We could consider first trying to load an SM implementation, and then falling back to ignoring the option, but it is probably not necessary as classes that don't start with a capital letter are rare and discouraged.