Why Purpose Slf4j Over Log4j For Logging Inward Java

Every Java programmers know that logging is critical for whatever Java application, peculiarly server-side application, as well as many of them are already familiar alongside diverse logging libraries e.g. java.util.logging, Apache log4j, logback, but if you lot don't know almost SLF4J, Simple logging facade for Java,  thus it's fourth dimension to acquire as well as purpose SLF4J inward your project. In this Java article, nosotros volition acquire why using SLF4J is amend than using log4j or java.util.logging. It’s been a long time, since I wrote 10 logging tips for Java programmer,I don’t recollect anything I convey writing almost logging. Anyway, let’s acquire dorsum to the topic, on opposite to all those logging libraries, in that location is a major departure betwixt them as well as SLF4J. SLF4J or Simple logging Facade for Java is non actually a logging implementation, instead, it's an abstraction layer, which allows you lot to purpose whatever logging library inward the back-end. If you lot are writing API or utility library, which tin hold upwards used internally or externally, thus you lot actually don't desire that whatever client, which uses your library, should besides stick alongside your selection of logging library. 

Suppose, if a projection is already using log4j, as well as you lot included a library say Apache Active MQ, which has dependency on logback, about other logging library, thus you lot postulate to include them every bit well, but if Apache Active MQ uses SL4J, you lot tin dice on alongside your logging library, without hurting of adding as well as maintaining novel logging framework. 

In brusk SLF4J brand your code independent of whatever detail logging API, which is adept think for populace API developers. Though sentiment of abstracting logging library is non novel as well as Apache common logging is already using it, but at nowadays SLF4J is chop-chop becoming an measure for logging inward Java world. 

Let's run across duet of to a greater extent than argue to purpose SLF4J over log4j, logback or java.util.logging.



Prefer SLF4J over Log4J, logback as well as java.util.Logging

Every Java programmers know that logging is critical for whatever Java application Why purpose SLF4J over Log4J for logging inward Java
As I said earlier, primary motivation of using SLF4J inward your code to write log statements is, to brand your program, independent of whatever detail logging library, which powerfulness require dissimilar configuration than you lot already have, as well as innovate to a greater extent than maintenance headache. But apart from that, in that location is i to a greater extent than characteristic of SLF4J API, which convinced me to purpose SL4J over my long fourth dimension favorite Log4j, that is know every bit house holder as well as represented every bit {} inward code. Placeholder is pretty much same every bit %s inward format() method of String, because it acquire substituted  by actual string supplied at runtime. This non exclusively bring down lot of String concatenation inward your code, but besides terms of creating String object. This is truthful fifty-fifty if you lot powerfulness non postulate that, depending upon your log score inward production environs e.g. String concatenation on DEBUG as well as INFO levels. Since Strings are immutable as well as they are created inward String pool, they eat heap memory as well as most of the fourth dimension they are non needed e.g. an String used inward DEBUG declaration is non needed, when your application is running on ERROR score inward production. By using SLF4J, you lot tin defer String creation at runtime, which agency exclusively required Strings volition hold upwards created. If you lot convey been using log4j thus you lot already familiar alongside a workaround of putting debug declaration within if() condition, but SLF4J placeholders are much amend than that.

This is how you lot would create inward Log4j, but sure as shooting this is non fun as well as bring down readability of code past times adding unnecessary boiler-plate code.


if (logger.isDebugEnabled()) {     logger.debug("Processing merchandise alongside id: " + id + " symbol: " + symbol); }


On the other manus if you lot purpose SLF4J, you lot tin acquire same lawsuit inward much concise format every bit shown below :


logger.debug("Processing merchandise alongside id: {} as well as symbol : {} ", id, symbol);


In SLF4J, nosotros don't postulate String concatenation as well as don't incur terms of temporary non postulate String. Instead, nosotros write log message inward a template format alongside placeholder as well as provide actual value every bit parameters. You powerfulness hold upwards thinking almost what if I convey multiple parameters, good you lot tin either purpose variable arguments version of log methods or exceed them every bit Object array. This is actually convenient as well as efficient way of logging. Remember, before generating concluding String for logging message, this method banking concern check if a detail log score is enabled or not, which non exclusively bring down retention consumption but besides CPU fourth dimension involved for executing those String concatenation didactics inward advance. Here is the code of SLF4J logger method from it's Log4j Adapter shape Log4jLoggerAdapter from slf4j-log4j12-1.6.1.jar.


public void debug(String format, Object arg1, Object arg2) {     if (logger.isDebugEnabled()) {       FormattingTuple ft = MessageFormatter.format(format, arg1, arg2);       logger.log(FQCN, Level.DEBUG, ft.getMessage(), ft.getThrowable());     } }


It's besides worth knowing that logging has severe acquit on on performance of application, as well as it's e'er advised to exclusively mandatory logging inward production environment.

How to purpose SLF4J alongside Log4J for logging

Apart from inward a higher house benefits, I think in that location is i caveat though, inward gild to purpose SLF4J you lot non exclusively postulate to include SLF4J API Jar e.g. slf4j-api-1.6.1.jar, but besides companion JAR, depending upon which logging library, you lot are using inward backend. Suppose If you lot desire to use SLF4J, Simple Logging Facade for Java,  along alongside Lo4J, you lot postulate to include next jars inward your classpath, depending upon which version of SLF4J as well as log4J you lot are using e.g.

 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 lot are using Maven to mange dependency inward your project, you lot tin but include SLF4J JAR, as well as maven volition include it's subject companion JAR. In gild to purpose Log4J along alongside SLF4J, you lot tin include next dependency inward your project's pom.xml

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

By the way, if you lot are interested inward using variable declaration version of logger methods, than include SLF4J 1.7 version.

Summary

To summarize this post, I would advise next reasons are adept plenty to select SLF4J over Log4j, common logging, logback or java.util.logging directly.

1) Using SLF4J inward your opened upwards origin library or internal library, volition acquire inward independent of whatever detail logging implementation, which agency no postulate to create out multiple logging configuration for multiple libraries, your customer volition going to appreciate this.

2) SLF4J provides house holder based logging, which improves readability of code past times removing checks prevarication isDebugEnabled(), isInfoEnabled() etc.

3) By using SLF4J logging method, you lot defer terms of constructing logging messages (String), until you lot postulate it, which is both retention as well as CPU efficient.

4) As a side note, less release of temporary strings agency less travel for Garbage Collector, which agency amend throughput as well as functioning for your application.

These advantages are but tip of iceberg, you lot volition acquire almost to a greater extent than benefits, when you lot commencement using SL4J as well as reading almost it.  I strongly suggest, whatever novel code evolution inward Java, should purpose SLF4J for logging over whatever other logging API including log4J.


Further Learning
Complete Java Masterclass
Java Fundamentals: The Java Language
Java In-Depth: Become a Complete Java Engineer!

0 Response to "Why Purpose Slf4j Over Log4j For Logging Inward Java"

Post a Comment

Iklan Atas Artikel

Iklan Tengah Artikel 1

Iklan Tengah Artikel 2

Iklan Bawah Artikel