SLF4J-An abstraction layer that allows you to unify the logging API

First, what is SLF4J

when we do Java development, if we need to log logs, there are many log APIs to choose from, such as:

• Java.util.logging
• Apache log4j
• Logback

What is slf4j again? Why is it better to use slf4j than to use log4j or java.util.logging? This is because SLF4J does not really implement logging compared to all of the mentioned logging libraries, but instead it is just a layer of abstraction that allows you to use any of the back-end log records libraries.

If you are writing an API or application library that is used internally or externally, then you really don't need to let the client that uses the library you write choose to use some kind of log library.

Assuming the project already uses log4j, and you include a library called Apache Active MQ, which also relies on another logging library logback, you need to include them,

However, if Apache Active MQ uses SLF4J, you can continue to use your logging library without the painful need to add and maintain a new logging framework.

In short, SLF4J makes your code independent of any particular logging API, a good idea especially for API developers of public components.

Although the abstract concept of the logging library is not new, the Apache Commons Logging Logging Library also uses this concept, but now SLF4J will soon become the standard logging repository in the Java World .

Let's look at some of the reasons to use SLF4J without using Log4j,logback or java.util.logging.

Second, prefer to use slf4j also reluctant to use Log4j,logback and java.util.Logging? 1. Independent of any log logging API library

As mentioned earlier, the primary motivation for writing a logging statement in code to use SLF4J is to make your program independent of any particular logging library, which may need to be configured differently than you are now, and introduce more headaches for maintenance issues.

2. Placeholder function

In addition to this, the SLF4J API also has a feature that lets you use slf4j rather than a long-term interest in log4j, which is the placeholder function , which is represented in the code with {}.

The placeholder function is very similar to the%s in the format () method of string because it extracts the actual string provided at run time. This not only reduces the number of string connections in the code, but also decreases the resources required to create the string object.

The same effect can be achieved even if your production environment log level, such as the debug and info-level string connections, may not be needed.

Because strings are immutable and they are created in a string pool that use heap memory, strings are not required in most cases when the application is running at the error level in a production environment, such as strings in a debug statement.

By using SLF4J, you can delay the creation of a string to run time, which means that it is created only when a string is needed.

If you have already used log4j, you are already familiar with the work scenario where you put the debug statement within the IF () condition, and the slf4j placeholder function is better suited for this scenario than the log4j.

Third,How to use SLF4J and log4j to log

The use of SLF4J requires the introduction of Slf4j-api-1.6.1.jar, as well as the introduction of collaborative jar packages, and what jar packages depend on what log ToolPak you use on the backend.
If you want to work with SLF4J and lo4j boarding, then you need to bring the following jar packages into your classpath,
The specific version depends on the version of SLF4J and log4j you are using, such as:
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 use MAVEN to manage project dependencies, you can introduce only the slf4j jar, and Maven will introduce the other jar packages it relies on.
In order to use log4j and slf4j, you can add the following dependencies in your project's Pom.xml

By the way, if you are interested in using the logging method with the parameter version, you will need to introduce the SLF4J 1.7 version.

Iv. Summary

Choose SLF4J instead of directly choosing log4j, commons Logging, Logback or java.util.logging for the following reasons:

1) using SLF4J in your open source or private libraries can be independent of any log implementation, which means that you do not need to manage multiple libraries and multiple log files. Your client will appreciate this.

2) slf4j provides placeholder logging, which improves the readability of the code by removing checks for isdebugenabled (), isinfoenabled (), and so on.

3) by using logging methods, the log information (string) is not constructed until you use it, which increases both memory and CPU usage.

4) Make a side note, the less the temporary string, the less work the garbage collector means, which means better throughput and performance for your application.

These advantages are just the tip of the iceberg, and when you start using sl4j and read it, you'll learn more about the benefits. I strongly recommend that any new code development in Java should use SLF4J instead of any log API, including log4j.

SLF4J-An abstraction layer that allows you to unify the logging API