{"id":563,"date":"2011-09-13T20:05:00","date_gmt":"2011-09-13T20:05:00","guid":{"rendered":"http:\/\/www.javacodegeeks.com\/2012\/10\/the-java-logging-mess.html"},"modified":"2012-10-21T20:16:41","modified_gmt":"2012-10-21T20:16:41","slug":"java-logging-mess","status":"publish","type":"post","link":"https:\/\/www.javacodegeeks.com\/2011\/09\/java-logging-mess.html","title":{"rendered":"The Java Logging Mess"},"content":{"rendered":"
Every application needs logging. And right now there are a lot of options on what exactly to use for logging in Java. The most famous frameworks are: log4j, logback, commons-logging, slf4j, java.util.logging. And there are a lot more \u2013 every now and then someone decides to write his own logger \u2013 just go to the Open Type dialog of your IDE and type \u201cLogger\u201d (not to mention that some use the name \u201cLog\u201d). And there\u2019s also the ServletContext.log(..) and stuff like that. It is indeed a mess. But let\u2019s start with some history (note: here\u2019s another post<\/a> on the topic) .<\/p>\n

First there was System.out and System.err. But they were inflexible, so a need for a feature-rich logging has arisen (note that I was in elementary school at that time). Logging that can be customized format, that can go to multiple targets \u2013 files, consoles, emails, etc. So log4j has appeared \u2013 in 1999<\/a>.<\/p>\n

But other solutions spawned as well, including java.util.logging \u2013 an attempt to have standard JDK logging. Note a very successful attempt, as it turned out. java.util.logging appeared with JDK 1.4 in the beginning of 2002. A few months later the realized need for a common logging interface for all existing loggers resulted in apache common-logging<\/a>.<\/p>\n

The idea of commons-logging was viable \u2013 libraries should not force a particular logging implementation on applications that use them. So each logging implementation gets adapted to a common API which is used by the library \u2013 so your library does not use org.apache.log4j.Logger \u2013 it uses org.apache.commons.logging.Log, and it delegates to whatever logging framework exists on the classpath. That way your project can use multiple libraries and use a single logging configuration for all of them.

<\/div> <\/div><\/p>\n

But commons-logging was not good enough. People say<\/a> that it has caused more problems than it has solved. So the author of log4j \u2013 Ceki G\u00fclc\u00fc<\/a> created a new project \u2013 slf4j (Simple Logging Facade for Java) in 2005<\/a>. It aims to be a better commons-logging.<\/p>\n

Log4j has been widely used since 1999, but it was not good enough, so guess who created a new project \u2013 logback. It was Ceki G\u00fclc\u00fc again. Why a new project? Well, combination of political reasons and old code base that needs replacing from the ground, I guess. Anyway, logback appeared in 2006. How it is better than log4j? Ceki explains here<\/a>.<\/p>\n

So back to present day \u2013 there are a lot of logging frameworks and two facades \u2013 commons-logging and slf4j. Every library uses a different one, and it\u2019s a mess. Version mismatches, tons of Logger classes on the classpath. Maven succeeds at making this simpler by at least not allowing multiple versions of the same logging implementation, but that\u2019s it. And if you don\u2019t know all the history above and which framework is used for what, it is likely for your project to suffer from that mess.<\/p>\n

What\u2019s the solution? The simplest thing is to use slf4j and logback. Why?<\/p>\n