LoggerApis - m-m-m/util GitHub Wiki
There are million of logger APIs around the world:
- Commons-Logging (http://commons.apache.org/logging/apidocs/org/apache/commons/logging/Log.html)
- Log4J (http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/Logger.html)
- Java (https://docs.oracle.com/en/java/javase/11/docs/api/java.logging/java/util/logging/Logger.html)
- SLF4J (http://www.slf4j.org/api/org/slf4j/Logger.html)
- JBoss (https://docs.jboss.org/jbosslogging/latest/org/jboss/logging/Logger.html)
- Avalon/Excalibur (http://excalibur.apache.org/apidocs/org/apache/avalon/framework/logger/Logger.html)
- DNA (http://dna.codehaus.org/apidocs/org/codehaus/dna/class-use/Logger.html)
- Logkit (http://excalibur.apache.org/apidocs/org/apache/log/Logger.html)
- DPML (http://api.dpml.net/dpml/2.0.0/net/dpml/util/Logger.html)
- Eclipse EMF (http://help.eclipse.org/help32/topic/org.eclipse.emf.doc/references/javadoc/org/eclipse/emf/common/util/Logger.html)
- SAP (http://help.sap.com/javadocs/nwmobile/SP3/handhelds/com/sap/tc/mobile/wdlite/progmodel/util/Logger.html)
- BEA (http://e-docs.bea.com/workshop/docs81/doc/en/portal/java-class/com/beasys/commerce/util/Logger.html)
- UCAR (http://www.unidata.ucar.edu/software/netcdf/java/docs/ucar/util/Logger.html)
- JRUNX (http://livedocs.adobe.com/jrun/4/javadocs/jrunx/logger/Logger.html)
- Reactor (https://github.com/reactor/reactor-core/blob/main/reactor-core/src/main/java/reactor/util/Logger.java) - yes, even in 2017 people are ignorant enough to create their own logger APIs.
So the last thing we need for our project, is creating yet another logger API. We need to choose a meta-logger that allows to bridge to common logger implementations such as log4j or java.util.logging.
Still the problem is that when open-source projects are glued together they may use different meta-loggers. So there should be a common sense about THE logger API. The only possible candidates are commons-logging and slf4j.
We started with commons-logging but after people complained about their classloader-problems and other projects started to switch to slf4j we decided to do so, too. The design of slf4j is very simple but that is what makes it so nice. I would still love to see some nice Logger interface in java.util.logging but this will probably never happen. So I hope that slf4j will become common sense in (open-source) java projects so integration will cause less headaches and you do not end up with 100 logger-JARs in your classpath.
Now after we migrated to slf4j we regret our decision. It is causing trouble when combining open-source libraries that depend on it in different versions. In this case commons-logging was better. As simple interface as API that never changed over the time.
SLF4J: The requested version 1.6 by your slf4j binding is not compatible with [1.5.5, 1.5.6, 1.5.7, 1.5.8, 1.5.9, 1.5.10, 1.5.11]
SLF4J: See http://www.slf4j.org/codes.html#version_mismatch for further details.
Exception in thread "main" java.lang.NoSuchMethodError: org.slf4j.helpers.MessageFormatter.format(Ljava/lang/String;Ljava/lang/Object;Ljava/lang/Object;)Lorg/slf4j/helpers/FormattingTuple;
This seems to be by design: http://www.slf4j.org/faq.html#compatibility
SLF4J sucks