[pointyhat]

This is the typical result of "enterprise" applications which are more interested in decoupling the logging system from the framework versus picking one that works.

Over-abstraction at work.

There is a "commons logging" for .Net as well which replicates the entire log4net API 1:1. That is where the crazy starts to set in.

[kjetil]

That's a reasonable (if knee-jerk) first reaction. But reality is a bit more complicated.

log4j was the first de facto standard (excluding System.out). Making it part of the standard API would have been a no-brainer. Unfortunately, java.util.logging sucks (hard to customize, coupling with J2EE app servers). So people keep using log4j.

Library writers now have a problem: How do you choose which logging framework to use? You really want to use the same framework as your users, the developers making apps. Thus was born commons-logging.

commons-logging has a number of problems, including non-deterministic setup and being bundled with some common app servers (which creates its own share of problems).

Thus: slf4j. Which works.

I agree with the author that slf4j is the way to go. Alternatively you can just use log4j directly. But slf4j has one feature which log4j doesn't: format strings. If you've ever had to add "if (log.isDebuggingEnabled())" checks to logging code you'll appreciate what a difference this makes.

In conclusion: Java logging is a clusterfuck, but if you know what to use you'll be fine. The end.

[DanielRibeiro]

Even for ruby you can find many logging libraries:

https://github.com/parolkar/active_log

https://github.com/colbygk/log4r

https://github.com/TwP/logging

https://github.com/relevance/log_buddy

I believe one of the reasons is that logging is not a simple problem, but it is ubiquitous to all applications.

It is not simple because:

1. your logging is usually a crosscutting concern to applications, and is really fit for Aspect Oriented Programming Mechanisms.[1] In language with mixins, like Ruby and Scala, this is not a big issue, as you don't need full AOP to solve this. AspectJ is not really widespread, and adds quite a lot of complexity to a small project, and is not standard Java, which makes a bad situation worse on Java.

2. your logging must be easy to disable, and only compute what it is actually needed. With languages with closures and Ast Metaprogramming, like Lisp Macros, you can do this very easily. Scala is particularly suitable to this, as you can use call by name[2] semantics to make the closures implicit.

[1] http://en.wikipedia.org/wiki/Aspect-oriented_programming

[2] http://www.scala-lang.org/node/138