Class.getClassLoader0 was once an expensive native operation, but since JDK-6642881 was fixed it is now a simple getter, retrieving a final field injected during class load. Thus the advice in StringCoding that getClass().getClassLoader0 is expensive is now wrong.

While JDK-8047735 may prove to make the getSecurityManager calls faster in the future, it seems like we should at least clean up the advice and possibly flip statements that are checking getSecurityManager since always having a volatile read is now likely the relatively more expensive operation here, e.g.:

  boolean isTrusted = System.getSecurityManager() == null ||
    cs.getClass().getClassLoader0() == null;