I have been pushing SLF4J for a long time now… When talking with other developers, (even when I talk to myself!) they have such strong convictions to “how they implemented it last time”, that it is really hard to get them to consider something different. Especially when it is as boring as logging!
I can’t tell you how many App1Logger.java, App2Logger.java, logger framework implementations I have seen over the years. When JDK 1.4 logging was introduced, (good or bad), I jumped on it. It was nice to not have to “have discussions” about what logging API we were going to use. I personally hated all of the wrappers (this dislike goes beyond logging wrappers too!)
So where is this going? I had an interesting idea yesterday when talking to someone about SLF4J. I believe that SLF4J is more of an API than an implementation. SFL4J provides a logging API and a collection of plug-able implementations. One could say that JCL (Jakarta Commons Logging) is an API, but also includes a “magic” implementation picker. This implementation picker is wired into JCL, defining a specific implementation philosophy. This philosophy has proven to be way more pain than gain. As for as the JDK1.4 and Log4J frameworks, I would classify them as purely implementations, with a matching, uncouple-able API.
Then it hit me… I can roll my own implementation and plug it in under SLF4J. I really don’t what to roll my own, but the point is that I can add custom behavior to my logging system without creating a wrapper framework. I think this is pretty cool!
So, that really only leaves one question: do you like the SLF4J logging API? Sure, it has some short coming, but what code does not? Overall, I think it is a perfectly sufficient API for the needs of anything I’ve encountered.
Once again.. call me crazy!
