Why Purpose Slf4j Over Log4j For Logging Inwards Java

Every Java programmers know that logging is critical for whatsoever Java application, particularly server-side application, as well as many of them are already familiar amongst diverse logging libraries e.g. java.util.logging, Apache log4j, logback, but if yous don't know almost SLF4J, Simple logging facade for Java,  as well as then it's fourth dimension to acquire as well as operate SLF4J inwards your project. In this Java article, nosotros volition acquire why using SLF4J is ameliorate 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 bring writing almost logging. Anyway, let’s acquire dorsum to the topic, on opposite to all those logging libraries, in that location is a major deviation 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 yous to operate whatsoever logging library inwards the back-end. If yous are writing API or utility library, which tin live used internally or externally, as well as then yous actually don't desire that whatsoever client, which uses your library, should every bit good stick amongst your selection of logging library. 

Suppose, if a projection is already using log4j, as well as yous included a library say Apache Active MQ, which has dependency on logback, merely about other logging library, as well as then yous remove to include them every bit well, but if Apache Active MQ uses SL4J, yous tin proceed amongst your logging library, without hurting of adding as well as maintaining novel logging framework. 

In brusk SLF4J brand your code independent of whatsoever item logging API, which is adept think for populace API developers. Though sentiment of abstracting logging library is non novel as well as Apache park logging is already using it, but at nowadays SLF4J is rapidly becoming an criterion for logging inwards Java world. 

Let's run across brace of to a greater extent than argue to operate 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 whatsoever Java application Why operate SLF4J over Log4J for logging inwards Java
As I said earlier, master copy motivation of using SLF4J inwards your code to write log statements is, to brand your program, independent of whatsoever item logging library, which powerfulness require unlike configuration than yous 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 operate SL4J over my long fourth dimension favorite Log4j, that is know every bit house holder as well as represented every bit {} inwards code. Placeholder is pretty much same every bit %s inwards format() method of String, because it acquire substituted  by actual string supplied at runtime. This non alone trim back lot of String concatenation inwards your code, but every bit good toll of creating String object. This is truthful fifty-fifty if yous powerfulness non remove that, depending upon your log bird inwards production surroundings e.g. String concatenation on DEBUG as well as INFO levels. Since Strings are immutable as well as they are created inwards String pool, they swallow heap memory as well as most of the fourth dimension they are non needed e.g. an String used inwards DEBUG declaration is non needed, when your application is running on ERROR bird inwards production. By using SLF4J, yous tin defer String creation at runtime, which agency alone required Strings volition live created. If yous bring been using log4j as well as then yous already familiar amongst a workaround of putting debug declaration within if() condition, but SLF4J placeholders are much ameliorate than that.

This is how yous would produce inwards Log4j, but certainly this is non fun as well as trim back readability of code past times adding unnecessary boiler-plate code.


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


On the other paw if yous operate SLF4J, yous tin acquire same lawsuit inwards much concise format every bit shown below :


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


In SLF4J, nosotros don't remove String concatenation as well as don't incur toll of temporary non remove String. Instead, nosotros write log message inwards a template format amongst placeholder as well as provide actual value every bit parameters. You powerfulness live thinking almost what if I bring multiple parameters, good yous tin either operate variable arguments version of log methods or travel past times them every bit Object array. This is actually convenient as well as efficient way of logging. Remember, before generating lastly String for logging message, this method banking enterprise check if a item log bird is enabled or not, which non alone trim back retention consumption but every bit good CPU fourth dimension involved for executing those String concatenation educational activity inwards advance. Here is the code of SLF4J logger method from it's Log4j Adapter bird 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 every bit good worth knowing that logging has severe comport on on performance of application, as well as it's e'er advised to alone mandatory logging inwards production environment.

How to operate SLF4J amongst Log4J for logging

Apart from inwards a higher house benefits, I think in that location is i caveat though, inwards guild to operate SLF4J yous non alone remove to include SLF4J API Jar e.g. slf4j-api-1.6.1.jar, but every bit good companion JAR, depending upon which logging library, yous are using inwards backend. Suppose If yous desire to use SLF4J, Simple Logging Facade for Java,  along amongst Lo4J, yous remove to include next jars inwards your classpath, depending upon which version of SLF4J as well as log4J yous 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 yous are using Maven to mange dependency inwards your project, yous tin merely include SLF4J JAR, as well as maven volition include it's subject companion JAR. In guild to operate Log4J along amongst SLF4J, yous tin include next dependency inwards 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 yous are interested inwards 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 pick out SLF4J over Log4j, park logging, logback or java.util.logging directly.

1) Using SLF4J inwards your opened upward rootage library or internal library, volition acquire inwards independent of whatsoever item logging implementation, which agency no remove to contend 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, yous defer toll of constructing logging messages (String), until yous remove it, which is both retention as well as CPU efficient.

4) As a side note, less let out of temporary strings agency less piece of job for Garbage Collector, which agency ameliorate throughput as well as functioning for your application.

These advantages are merely tip of iceberg, yous volition acquire almost to a greater extent than benefits, when yous initiative of all using SL4J as well as reading almost it.  I strongly suggest, whatsoever novel code evolution inwards Java, should operate SLF4J for logging over whatsoever other logging API including log4J.


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

Belum ada Komentar untuk "Why Purpose Slf4j Over Log4j For Logging Inwards Java"

Posting Komentar

Iklan Atas Artikel

Iklan Tengah Artikel 1

Iklan Tengah Artikel 2

Iklan Bawah Artikel