Description
When using SLF4J in a WebSphere Application Server with a security policy that forbids "createSecurityManager", startup of SLF4J fails with a java.security.AccessControlException. Since you can't override the Constructor of SecurityManager and disable this check (which would defeat the purpose of the SecurityManager), I think the best way to handle this is Lazy Initialisation of SECURITY_MANAGER in org.slf4j.helpers.Util.
I don't know how performance-critical this is, but since it's currently only used for a debugging feature that can be disabled in a production environment, I see no harm.