The “Break it Down” Blog

If you are like me, you can’t decide on a logging framework for your Java applications. JDK Logging is so easy, Log4J logging is lauded as a “must-used replacement for JDK “crap” logging” and in one new project I downloaded I noticed the use of SLF4J (Simple Logging Framework for Java) for the first time. Oh god not another logging framework.

Well today I ran across a blog entry discussing a new logging framework, LogBack, which is built ontop of SLF4J (Ok so I guess SLF4J is a framework?) and is intended as the successor to Log4J. LogBack was also done by Log4J’s original author, Ceki Gülcü. It looks like there was a interm logging framework in there between creating the SLF4J framework and then eventually LogBack, and that is NLOG4J. I believe NLOG4J was intended to be a drop-in replacement of Log4J, but regardless, the new logging framework here is LogBack.

LogBack, as with most successful logging libraries (commons-logging is another) uses pluggable logging. You can switch out your underlying logging library redily and not change any logging code. The code looks similar to what we would expect:

Logger logger = LoggerFactory.getLogger("chapter1.HelloWorld1");
logger.debug("Hello world.");

NOTE: I always prefer to use ClassName.class.getName() (where ClassName is the name of my class, “HelloWorld1″ in this case) when requesting a logger so my changes respond to refactor operations. If you leave your getLogger call as a String you will manually have to change it every time your class changes names or location (or your code). I just used the snippet above because it’s directly from the LogBack getting started guide.

Loggers/Appenders/Layouts look the same as they did from Log4J… I have a feeling, given how many frameworks this developer has started over the years, that more than this being a revolutionary different design, he most likely has just been refining the code and design each time. Making the core functionality more generic and the specific functionality more clearly pulled out/separated from the core. This is evident in the libraries you add to your build path now, no more single log4j.jar file.

Either way, my guess is that there is so much spit, polish and good/robust design in this API that if you REALLY need a powerful logging facility this is going to be the way to go. If you just like spitting out “Object not null” to your console every now and again, stay with JDK Logging, it’s sufficient.