Negative Engery

I’ve reached a point where I really need a logging framework for a small library. The trouble with logging in small libraries is that you want to avoid using a full logging system like Log4J or java.util.logging so that applications that use your library are still free to pick the logging system they want to use. Jakarta Commons Logging has been the de-facto solution for these situations for quite a while now, but it’s a library that people love to hate because of “class loading issues”. Now I happen to know a fair bit about class loaders, I know why the problems occurred with Commons Logging, I know how to avoid them, work around them and I understand why they’re not a fundamental flaw of commons logging. However, I also know that commons logging is a very simple logging framework and there is scope for a project to build on the basic idea of commons logging but provide more power and flexibility rather than just the absolute lowest common denominator functionality.

For example, it would be nice to have a way of avoiding the cost of string concatenation if the log message isn’t going to be displayed anyway. With commons logging you have to do:

if (log.isDebugEnabled()) log.debug(“Stuff: ” + stuff);

It would be nice to not have to think about that stuff and there are a few options to achieve that kind of thing. There’s other things that might be nice to have in a simple logging framework that is outside the scope of what commons logging is trying to achieve too.

One of the alternatives that does provide a solution to the ugly if above, is SLF4J. I’m happy to use it over commons logging just for that feature, but reading the website and the documentation I just don’t feel comfortable with it. The whole vibe is negative and anti-commons-logging. It’s a shame, I set out looking for a logging framework with a wider scope, something that was looking to innovate a little and make my life easier, but SLF4J just seems to be out to kill commons logging and nothing more. Just take a look at the project description from the SLF4J website:

The Simple Logging Facade for Java or (SLF4J) is intended to serve as a simple facade for various logging APIs allowing to the end-user to plug in the desired implementation at deployment time. SLF4J also allows for a gradual migration path away from Jakarta Commons Logging (JCL). Wouldn’t it be better to highlight the good points of SLF4J instead of the perceived negative points against JCL? Why would someone who understands and can work with class loaders, whose never had a problem with commons logging, use SLF4J? At least for me, it seems harder to manage a bunch of different jar files and try and get my users to pick the right one for the right situation than it is to just use commons logging and be done with it.

Maybe I shouldn’t care why a library was developed, but it just seems such a shame that there’s so much negative energy around the project when there are positive things that could have been said instead. Oh well, I don’t think I could live with a debug(String) instead of a debug(Object) method anyway.