The -Dsun.misc.URLClassPath.disableJarChecking feature causes URLClassPath to report an exception for jars that don't start with LOCSIG.

Not starting with LOCSIG doesn't necessarily mean the jar is ill-formed: the implementation reads the jars 'backwards' by looking for the central directory, and some real-world jar files rely on this to have a prefix of non-jar content at the beginning of the file.

The feature is also currently broken, since all code paths that result in the exception being thrown go through an exception handler that catches and ignores the IOException: https://github.com/openjdk/jdk/blob/3e393047e12147a81e2899784b943923fc34da8e/src/java.base/share/classes/jdk/internal/loader/URLClassPath.java#L459-L461

Additionally, the feature is only enabled if `System.getSecurityManager() != null`, and the SecurityManager is deprecated for removal (https://openjdk.java.net/jeps/411).

Given all that, I think we should consider removing the logic related to -Dsun.misc.URLClassPath.disableJarChecking