My Soapbox for SLF4J

There seems to be a ruckus being generated lately over SLF4J. Both Howard and Dion have posted on the topic so far and they have their reasons. But I see that some things have been left out of the discussion, so I'll get on my soapbox for a bit to offer my own opinion.

<soapbox>
IMO, the most important point about JCL is that the use of it is most oftentimes incorrect from an architecture standpoint, and this is according to the creator of JCL, Rod Waldhoff:

'...The purpose of Commons Logging is not to somehow take the logging world by storm. In fact, there are very limited circumstances in which Commons Logging is useful. If you're building a stand-alone application, don't use commons-logging. If you're building an application server, don't use commons-logging. If you're building a moderately large framework, don't use commons-logging. If however, like the Jakarta Commons project, you're building a tiny little component that you intend for other developers to embed in their applications and frameworks, and you believe that logging information might be useful to those clients, and you can't be sure what logging framework they're going to want to use, then commons-logging might be useful to you...'

Here is Rod's full blog entry.

Additionally, back in 2004 Ceki posted an extremely good writeup about the shortcomings of JCL that addresses the classloader issues with JCL. Anyone who has ever been bitten by these issues has my sympathy because I've been there before as well. Even the latest Spring Framework project (Spring OSGi) doesn't use JCL. Instead, Spring-OSGi switched to SLF4J. My buddy Chris has a great blog entry about JCL classloader issues as well.

And using java.util.logging (JUL) is just not a good option. Sure it's baked into the core Java libraries, but it is a pain to reconfigure because there are really only two options: a) via the logging.properties file in the JRE, or b) by supplying system properties (-D) to the JVM. Why would I want to reconfigure logging for my entire JRE and I suppose I could supply even more system properties to the JVM but what PITA. And don't get me started about the JUL feature set lagging behind Log4J so horribly in the areas of formatters and handlers. This is exactly why the x4juli project was created.

SLF4J provides what the vast majority of people really wanted (and assumed they were getting) when they adopted JCL in their projects. That is, an abstraction layer for logging that allows you to plug in your logging framework of choice at deployment time. SLF4J statically binds to a particular logging implementation so that there is no automagic discovery for configuration. This gets around the whole JCL nightmare.

SLF4J also supports the MDC/NDC (Mapped Diagnostic Context/Nested Diagnostic Context) that are supported in Log4J. The trouble with using these from Log4J with JCL is that JCL won't let them through its facade. SLF4J also offers parameterized log messages which is a really nice feature. Though the FAQ explains it, here is some more info on parameterized logging.
</soapbox>

OK, that's my soapbox for today. Maybe I'll add more to this later.