SLF4J vs Log4j
Last modified on February 1st, 2016 by Joe.
Which one to use in my project either SLF4J or Log4j or both? Its been long since SLF4J came into picture and adopted heavily by projects all around. But certain things never get over. Like the difference between abstract class and interface in Java. Difference between SLF4j and Log4j is still a popular questions among ‘loggers’, should I say newbie loggers? In SO, still there are questions raised on this topic. So now its time we deal with it in Java Papers.
However we elaborate this question deserves only a one line answer. The question itself is wrong. SLF4J and Log4J focus on different areas and they are not similar components. SLF4 is a logging facade. The name says it all. SLF4J is Simple Logging Facade for Java. It is not a logging component and it does not do the actual logging. It is only an abstraction layer to an underlying logging component.
In the case of Log4j, it is a logging component and it does the logging instructed to do. Logically these are entirely two different things. So what would be the right question. Do I need an abstraction logging layer in my project. That is, should I use SLF4J. If you want to compare SLF4J, then the right comparison would be to compare with Apache Commons Logging.
Should I use SLF4J (Logging Abstraction)?
- It is better to use abstraction, always!
- You can change the implementation as you wish and need not be tied to a dependency.
- To make it clear, if you are using SLF4J along with Log4j, if required Log4j can be swapped with another logging framework like Logback without compiling the source code. Logback is the reference implementation for SLF4J.
- Many comparisons in the web really under weigh the point that SLF4J is an abstraction. I see that as THE point for using it over Log4j. SLF4J is not a replacement for Log4j but it works along with it.
- Will there be any change in the performance? Since already using a logging API is seen as a overhead when comes to performance optimization. This abstraction layer will not add significant overhead to the performance. If you have any data, please share it.
- How about the syntax, does SLF4J provides simpler syntax over Log4J? Do not compare it like that. Once you get used to the syntax of SLF4J, then you need not worry about syntax for different logging frameworks.
- So in summary, if have option to decide, then I recommend you to go with SLF4J. Then, which logging implementation to use Log4J or Logback or Java Logging or … There is no certain winner between the logging components as of now and its purely based on choice.
I recently did some research on whether to use log4j or logback for Kafka brokers that we have deployed. Kafka uses slf4j as an abstraction with log4j. In the process have found that log4j2 has lot of improvements over the 1.x versions, especially in terms of performance. I especially enjoyed reading this: https://www.grobmeier.de/log4j-2-performance-close-to-insane-20072013.html
short and crispm
Not clear?
Nice Explanation. Thank You
Thanks for sharing. But could you please explain the slf4j part with an example using logback or any other logging component?
About performance, I have read on internet that SLF4j helps in performance as it uses string immutability concept very well. For logging it provides place holders which will be replaced during runtime. So the no of string objects being created is less.
I am not sure how much impact this will add to improve performance, but I can think on this point when it comes to performance optimization with SLF4j.
Thank you Joe.. I like your blog a lot than a text book. Very nicely articulated. SLF4J is new for me.. It would be better if a short article on it is published..
We use log4J only but i came to know about other frameworks.. Thank you.
thankss
Not so clear, need more clarity to differentiate it
nice joe… thank you so much.. we are using log4j currently i can suggest my team to do new development in slf4j it will be better option i guess