News for hackers. Stuff that matters.
Re:Why a Logging Framework Should Not Log by theanomaly on Thursday May 05, 2016 @01:33PM (#11638108)
Whoa. The author recommends including slf4j-nop as an explicit dependency of libraries?! This means that when a developer writes an application and forgets to include an slf4j backend, instead of getting a warning that no backend is configured, that developer will get absolutely no output. This is really bad advice.
Re:Why a Logging Framework Should Not Log by phillord on Thursday May 05, 2016 @01:42PM (#11638200)
It's ugly advice. Wish there was a better alternative. Ideas on a post-card please.
Re:Why a Logging Framework Should Not Log by devonkim on Thursday May 05, 2016 @01:53PM (#11638285)
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.
Re:Why a Logging Framework Should Not Log by phillord2 on Thursday May 05, 2016 @03:52PM (#11639197)
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.