Why use SLF4J instead of log4j

This article is translated by Importnew-jaskey from javarevisited. Welcome to join the translation team. Reproduced please see at the end of the request.

Every Java programmer knows that logs are critical to any Java application, especially server-side programs, and many programmers are already familiar with various log libraries such as java.util.logging, Apache log4j, and Logback. But if you don't know slf4j(Simple logging facade for Java), then it's time to learn to use SLF4J in your project.
In this article, we will learn why using SLF4J is superior to log4j or java.util.logging. It's been a while since I wrote 10 log tricks for Java programmers, and I can't remember what I wrote about the logs.

Anyway, let's go back to this topic, SLF4J is different from other log class libraries, and it's a lot different. SLF4J (Simple logging facade for Java) is not a true log implementation, but rather an abstraction layer (abstraction layers), which allows you to use any of the Log class libraries in the background. If you are writing an API or generic class library that can be used inside and outside, you really don't want clients using your class library to use the Log class library of your choice.

If a project already uses log4j and you load a class library, say Apache Active mq--It relies on another log class library Logback, then you need to load it too. But if Apache Active MQ uses SLF4J, you can continue to use your log class library without words to endure the pain of loading and maintaining a new log framework.

In general, SLF4J makes your code independent of any particular log API, which is a good idea for developers of API developers. Although the idea of an abstract log class library is not new and Apache Commons logging is already using this idea, SLF4J is rapidly becoming the standard for logging in the Java World. Let's look at a few reasons to use SLF4J instead of log4j, Logback, or java.util.logging.

SLF4J Compare the advantages of Log4j,logback and java.util.Logging

As I said before, the main starting point for using SLF4J to write log statements in your code is to make your program independent of any particular log class library, depending on the specific classes that might require different configurations than you already have, and cause more maintenance headaches. But in addition to that, a SLF4J API feature that allows me to persist in using slf4j to abandon my long-cherished lof4j, is called a placeholder (place holder) and is represented in code as "{}" in the attribute. The placeholder is a very similar to%s in the format () method of string, because it is replaced at run time by a supplied actual string. This not only reduces the number of string connections in your code, but also saves the new string object. Even though you may not need those objects, this still holds, depending on the log level of your production environment, such as string connections at debug or info level. Because the string objects are non-modifiable and they are built in a string pool, they consume heap memory and most of the time they are not needed, such as when your application runs at the error level in the production environment, A string used in the debug statement is not required. By using SLF4J, you can delay the creation of strings at run time, which means that only the required string objects are created. And if you've already used log4j, you're already familiar with the workaround for using the debug statement in the IF condition, but the slf4j placeholder is much more useful than this.

This is the scenario you use in log4j, but this is certainly not interesting and reduces code readability because of the unnecessary cumbersome duplication code (boiler-plate code):

123	if(logger.isDebugEnabled()) {    logger.debug("Processing trade with id: " + id + " symbol: "+ symbol);}

On the other hand, if you use SLF4J, you can get results in a very concise format, as shown in the following:

1	logger.debug("Processing trade with id: {} and symbol : {} ", id, symbol);

In slf4j, we do not need a string connection and will not cause a temporary unnecessary string consumption. Instead, we write the log information in a template format that passes the actual value as a placeholder and as a parameter. You might be wondering, what if I have a parameter? Well, then you can choose to use the variable parameter version of the log method or the object array to pass. This is a fairly handy and efficient way to play the logging method. Remember that before producing the final log information string, this method checks whether a particular log level is open, which not only reduces memory consumption but also reduces the CPU time to process the string Connection command. Here is the code that uses the Slf4j log method, from the Log4j adapter class Log4jloggeradapter in Slf4j-log4j12-1.6.1.jar.

123456

< Code class= "Java keyword" >public void debug ( String format, Object arg1, Object arg2) { &NBSP;&NBSP;&NBSP;&NBSP; if (logger.isdebugenabled ()) {          formattingtuple ft = Messageformatter.format (format, arg1, arg2); &NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP; logger.log (FQCN, Level.debug, Ft.getmessage (), ft.getthrowable ()); &NBSP;&NBSP;&NBSP;&NBSP; } }

At the same time, we are also well worth knowing that logging is a significant impact on the performance of the application, only the necessary log records in the production process is what we recommend.

How to use SLF4J to do log4j logging

In addition to the above benefits, I think there is a caveat that, in order to use SLF4J, you need not only to include the SLF4J API jar package, such as Slf4j-api-1.6.1.jar, but also the relevant jar package, depending on the Log class library you use in the background. If you want to use SLF4J with log4j, simple Logging facade for Java, you need to include the following jar package in your classpath, depending on which slf4j and which version of log4j you are using. For example:

• Slf4j-api-1.6.1.jar–jar for SLF4J API
• Log4j-1.2.16.jar–jar for log4j API
• slf4j-log4j12-1.6.1.jar–log4j Adapter for SLF4J

If you are using MAVEN to manage your project dependencies, you only need to include the SLF4J jar package, and MAVEN will include its dependent packages. In order to use log4j with SLF4J, you can include the following dependencies in your project Pom.xml.

1234567891011

<dependency>    <groupId>org.slf4j</groupId>    <artifactId>slf4j-log4j12</artifactId>    <version>1.6.1</version></dependency><dependency>    <groupId>org.slf4j</groupId>    <artifactId>slf4j-log4j12</artifactId>    <version>1.6.1</version></dependency>

Also, if you are interested in logging methods that use variable parameter versions (variable argument version), then import the version of SLF4J 1.7.

Summarize

Summing up this, I suggest using slf4j instead of using log4j directly, Commons logging, Logback or java.util.logging are sufficient.

1. Using SLF4J in your open source or internal class library makes it independent of any particular log implementation, which means that you do not need to manage multiple log configurations or multiple log class libraries, and your client will appreciate that.
2. SLF4J provides a placeholder-based logging method, which improves code readability by removing the check isdebugenabled (), isinfoenabled (), and so on.
3. By using Slf4j's logging method, you can defer the overhead of building log information (srting) until you really need it, which is efficient for both memory and CPU.
4. As a note, fewer temporary strings mean that the garbage collector (garbage Collector) needs to do a better job, which means your application has better throughput and performance.
5. These benefits are just the tip of the iceberg, and you'll know more about the benefits when you start using sl4j and reading the code. I strongly suggest that any new Java programmer should use SLF4J as a log instead of using other log APIs, including log4j.

Read MORE:

• Http://javarevisited.blogspot.com/2013/08/why-use-sl4j-over-log4j-for-logging-in.html#ixzz2konULdTB

Original link: javarevisited translation: Importnew.com-jaskey
Link: http://www.importnew.com/7450.html

Why use SLF4J instead of log4j