**The warning issued by slf4j:

 
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/opt/uejlib2.13/slf4j-nop-1.7.30.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/c:/opt/uejlib2.13/slf4j-nop-1.7.30.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type [org.slf4j.helpers.NOPLoggerFactory]

The classpath consists primarily of jars below a directory, via '-classpath 'c:\opt\uejlib2.13*'

The following two jar files are among the approximately 140 jars that reside below c:\opt\uejlib2.13\:

/opt/uejlib2.13/slf4j-api-1.7.30.jar
/opt/uejlib2.13/slf4j-nop-1.7.30.jar

These jars are symlinks to these two files:

/home/philwalk/.coursier/cache/v1/https/repo1.maven.org/maven2/org/slf4j/slf4j-api/1.7.30/slf4j-api-1.7.30.jar
/home/philwalk/AppData/Local/Coursier/cache/v1/https/repo1.maven.org/maven2/org/slf4j/slf4j-nop/1.7.30/slf4j-nop-1.7

The SLF4J warning complains only about slf4j-nop-1.7.jar, but having two different versions of the path that differ only with respect to one of them having a drive letter ("C:") and the other not.

Because of the way the jar was specified (via a directory wildcard -classpath), there would not appear to be any way to fix this on the client side. We don't have the option of explicitly specifying individual classpath jars due to the very large number of dependencies, which would exceed the supported command line length.

If classpath entry paths were compared via the equivalent of "java.io.File.getCanonicalPath", the apparent duplication would be removed, making SLF4J less problematic for client code.

By the way, our project only pulls SLF4J in by way of a transitive dependency, and this spurious warning is a major nuisance for command line tools.

Thanks for your consideration!