Is there reason to avoid slf4j?

Question

Digging into some Java logging stuff, and question about slf4j. It seems awfully convenient, always doing the logging same way in .java files, worrying only about logger name, then doing all logging configuration by having right .jar and .properties/.xml files.

What are the reasons to use or not to use slf4j by default in any project?

In this particular case, log4j will actually doing the logging (some to file, some to stdout, some to database), and it is a maven project.

I'm hoping for simple "yeah, go for it" or "no, using slf4j is asking for trouble X" from somebody with experience.

Answer 1

Ok, I actually ended up not using slf4j, but instead using log4j directly, because slf4j just kept on using JDK14LoggerAdapter instead of Log4jLoggerAdapter or LogBack, and I got fed up trying to get it to work by tweaking dependencies...

The project in question is Jenkins plugin built with Maven2, that may have been the reason of complications. It really did not work by "just put these dependencies to .pom".

So, to answer my own question, a reason to not use slf4j is: less moving parts, less dependencies, less manuals and docs to read through, less questions to ask at SO/mailing lists.

Answer 2

We have been logging over the SLF4J API for 1.5 years now. Before that we used log4j directly. Now we use jboss.logging, with a logback intermezzo and had to change zero lines in our code for all the framework changing.

So, go for it ;)

Answer 3

Definitely use slf4j. It's the standard common logging interface of today and it finally does it right regarding the plugging in of actual logging implementations. Logback as the implementation is highly recommended, it is the successor of log4j, done by the same guy who quit log4j to it from the start, but straightening out the issues that couldn't be straightened out in log4j.