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.
Ceki Gulcu says:
JCL’s warts have been widely discussed in the past. Typically, when used in conjunction with Tomcat, JCL may transform actual errors in logging errors, significantly lengthening the time it takes to identify problems.
While SLF4J offers several API enhancements over JCL, its robustness is its main differentiator. SLF4J’s simplicity and robustness resonate very strongly with developers who have been bitten by JCL. For other developers who have not yet experienced problems with JCL, SLF4J may be perceived as anti-JCL.
As you justly observe, logging is a controversial subject. I also agree with you that SLF4J would probably be better off by emphasizing its positive points rather than trashing JCL.
Hen says:
Why not just use the JDK logging? Are you having to support old JDKs?
My general thinking on the logging thing is that there should be a Lang 3.0 (JDK 1.5+) that wraps the JDK logging with a small facade for any usable helper bits that are needed.
–
JCL 1.1 is supposed to have cleaned the warts up, though I think that might have been the swansong for the code as there’s not much need for it once you leave old JDKs behind.
Adrian Sutton says:
If everyone used JDK logging I’d be fine with that, but there are a lot of apps out there that still use Log4J and would be annoyed if a tiny little library made them configure and use JDK logging as well. Having an abstraction layer is great for avoiding just that problem. The main reason JCL doesn’t have a lot of development on it is because it has achieved it’s aims and it just works. JCL has a very narrow focus of what it should do and they’ve been very careful to stick with that narrow focus. Hopefully in time it will become unnessecary but for now it seems to still be needed.