Swapping classes

17Nov09

I’ve been thinking about the way Log4J, commons logging, SLF4J, Logback and the related libs blatantly swap classes with the same qualified names. Like, you take this jar out, put the other jar in and you’ve got a different implementation. One example is the StaticLoggerBinder.

The interface is defined in the API and there’s a default implementation there too, but if you want to change it, you make a class with the same qualified name and then swap another jar into your dependencies. A few years ago I would have said that’s way dodgy and shouldn’t be done. But now that I’ve used it for some time, I don’t really see what the big deal is. It’s the ultimate case of convention over configuration.

I have had the odd problem where transitive dependencies filter in and spoil the party, but largely, it’s as pain-free way to change the logging implementation as any. You just change your dependencies! It does get confusing occasionally, but once you get your head round your dependencies (which you should anyway), it seems a lot simpler than having even more configuration items. See this for an intuitive clarification of how it works with Log4J, SLF4J and a bizarre faking of Log4J that re-routes it to SLF4J.