Commons Logging may be harmful to your health

All of us know that decoupling your code from the frameworks you use is a really great thing. This is why bridge libraries like commons logging are really wonderful. Just imagine how much code you will be changing if you are using log4j APIs in all of you application classes, and then a decision was made to start using the java APIs instead. Think of how much code would be changed. But with commons logging, the code changes would be minimal. Another thing, look at how many open source projects that are using commons logging. This must mean that commons logging is a good thing, right? WRONG!

First, let us define the meanings of "good" and "bad" concerning libraries such as commons logging. I think, that a "good" library would be able to bridge your logging requests to the logging framework of your preference with minimum interference and a very small overhead. I don't have to mention here that it should be stable and bug free of course. Another thing, which I personally think that it's very important, is that it should be as simple as possible.

If we take a look at JCL (Jakarta Commons Logging), we'll find that a lot of those aspects are not met. JCL works in a quiet complex way. It has a discovery mechanism to see which logging library you have in your application, and then uses class loading to load the logger that will be used. Even though this does the job, this class loading solution has its drawbacks. First of all, this may cause a lot of problems if your application is in a strict class loading environment (like OSGI for example). Another thing, JCL has a bad history with it's class loading solution.

Version 1.04 of JCL that was released on the 16th of June 2004 had some serious problems with its class loading mechanism. Ceki Gülcü (the original author of log4j) wrote a marvelous article on the subject. He also wrote a great piece on JCL, but might be a little outdated. Even though version 1.1 of JCL, released about 2 years after 1.04, claims that the bug is fixed, it's still a risk to use it, especially for the complexity of this library.

Another thing that needs to be mentioned here is that Rod Waldhoff, the author of commons logging, wrote a blog entry in 2003, titled "Commons Logging was my fault", where, in the last part of it, he says where to use and, more importantly, not to use JCL. To conclude it, JCL should be used in small and tiny components that are intended to be used by other developers in their projects. Even with that, Erik van Oosten created a project called "Version 99 Does Not Exist", which is an empty JAR with a pom file and maven meta data, so that you would put it in your maven repository, so that libraries that depend on JCL would not download it from the net, since the empty JAR is version 99.

So what else should we use? Well, I think that SLF4J is a great project. It's a simple facade for various logging APIs. The beauty of it is that instead of the class loading solution, it is just a simple facade, where you just plug in the desired implementation at deployment time. It's a very simple solution, "perhaps even laughably so" as stated in their FAQ.

SLF4J is wonderful, simple, stable and can be used in strict class loading environments like OSGI. It can be used with log4j, jdk1.4 logging, SimpleLogger, logback and x4juli (the latter 2 provide native implementation of SLF4J APIs). It's very simple to migrate to SLF4J from JCL. Simply download "jcl104-over-slf4j.jar", and it will delegate JCL calls to SLF4J.

SLF4J also has a couple of great features, parameterized logging and MDC support. Parameterized logging can cause a significant increase in the performance. One last thing that I have noticed, which is quiet funny really, several apache projects use SLF4J instead of commons logging. This sure shows that SLF4J is on the right track.