Logback native VS Logback via SLF4J

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.

---

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...

1. It enables you to switch away from Logback if you ever need to
2. It does not cost you anything, even the imports are smaller ;)
3. 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.

---

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.