Logback native VS Logback via SLF4J

Question

I have gone through the following article regarding the logging frameworks available for Java: http://michaelandrews.typepad.com/the_technical_times/2011/04/java-logging-reconsidered.html

The author has mentioned using SLF4J with Logback. How is that different from using Logback directly. Wouldn't it be better if one uses Logback directly rather than going for SLF4J, since Logback is built on top of SLF4J.

I'm with you. Avoid abstraction hell by making things deterministic at compile time. — Sridhar Sarnobat, Aug 04 '18 at 05:04
That link has expired. The same article is here: http://massiveprogramming.blogspot.com/2015/08/java-logging-reconsidered-technical.html — Sridhar Sarnobat, Aug 04 '18 at 05:06

score 44 · Accepted Answer · answered May 01 '11 at 10:37

SLF4J is adding zero overhead to Logback since it is simply the interface that is implemented by Logback without any additional layer.

You should use SLF4J simply because...

It enables you to switch away from Logback if you ever need to
It does not cost you anything, even the imports are smaller ;)
Other people will love you for using SLF4J and hate you for using a specific logging framework directly if you ever release your code into the wild.

The only place where you'd access Logback directly would be while (re)configuring your logging manually in an application. The need for this arises occasionally but even in that case, working with Logback would be restricted to a single class or even method.

As a rule of thumb: libraries should always use a logging abstraction while applications define the logging they are using, optionally accessing it directly.

you may want to add a note on the {}-placeholders as they in my opinion are the killer facility in slf4j. — Thorbjørn Ravn Andersen, May 02 '11 at 11:06
But he just asked whether he should use SLF4J or Logback without abstraction. Both support {}. — Huxi, Jun 01 '11 at 09:17

score 5 · Answer 2 · answered Apr 29 '11 at 07:59

SLF4J adds almost no overhead and Logback has a native bindings to it.

If you know by 100% that you will not need to switch to other logging framework in the future, go with logback native. But SLF4J allows you some abstraction and you can switch logging backends in a blink.

Logback is not build on top of SLF4J. SLF4J is an abstraction framework for logging. It doesn't do any logging itself. It just provides unified interface for logging.

Logback native VS Logback via SLF4J

2 Answers2