On Sun, Apr 9, 2017 at 8:29 PM, Dave Cramer <pg@fastcrypt.com> wrote:
So far I have seen more benefits of using JUL than claims of performance degradation (and most of the claims are when using slf4j bridge). Of course there is more to do, it might be not the best choice but was that or introduce a optional dependency of SLF4J (wich is a bad idea based on the SLF4J developers https://www.slf4j.org/faq.html#optional_dependency) or simply introduce a direct dependency of SLF4J making a forced used of a dependency that not many want. This is like the chicken-egg problem.
How would the bridge degrade performance if logging is off ?
The jul-to-slf4j module does not reimplement the java.util.logging because packages under the java.* namespace cannot be replaced. Instead, jul-to-slf4j translates LogRecord objects into their SLF4J equivalent. Basically it means that when using log4j for example, the bridge can replace org.log4j packages with an implementation of slf4j, so it uses the slf4j bridge dependency instead of the log4j dependency, but with jul it can not do that (it's part of the JDK) and it construct the LogRecord object even when logging is off.