The JVM works this way after C programs popularized the precedent - refuse to run at all with a dynamic link error stating the shared library that was expected without any mention of what version of the library should be present in the LD_LIBRARY_PATH or that the shared library version expected actually doesn't match the ABI in some corner cases and silently fails during runtime. That's part of why customizable classloaders in the JVM exist.
That is not what is happening with SLF4J. The nop logger is present in the API artifact. The API artifact chooses to warn when using it. The nop dependency, despite the name, contains no logger at all. It just explicitly forces the usage of the nop logger.
It's pretty clever actually, and works in a straight-forward way.
devonkim|9 years ago
phillord2|9 years ago
It's pretty clever actually, and works in a straight-forward way.