Why not use java.util.logging?

Disclaimer: I am the founder of log4j, SLF4J and logback projects.

There are objective reasons for preferring SLF4J. For one, SLF4J allows the end-user the liberty to choose the underlying logging framework. In addition, savvier users tend to prefer logback which offers capabilities beyond log4j, with j.u.l falling way behind. Feature-wise j.u.l may be sufficient for some users but for many others it just isn't. In a nutshell, if logging is important to you, you would want to use SLF4J with logback as the underlying implementation. If logging is unimportant, j.u.l is fine.

However, as an oss developer, you need to take into account the preferences of your users and not just your own. It follows that you should adopt SLF4J not because you are convinced that SLF4J is better than j.u.l but because most Java developers currently (July 2012) prefer SLF4J as their logging API. If ultimately you decide not to care about popular opinion, consider the following facts:

1. those who prefer j.u.l do so out of convenience because j.u.l is bundled with the JDK. To my knowledge there are no other objective arguments in favor of j.u.l.
2. your own preference for j.u.l is just that, a preference.

Thus, holding "hard facts" above public opinion, while seemingly brave, is a logical fallacy in this case.

If still not convinced, JB Nizet makes an additional and potent argument:

Except the end user could have already done this customization for his own code, or another library that uses log4j or logback. j.u.l is extensible, but having to extend logback, j.u.l, log4j and God only knows which other logging framework because he uses four libraries that use four different logging frameworks is cumbersome. By using SLF4J, you allow him to configure the logging frameworks he wants, not the one you have chosen. Remember that a typical project uses myriads of libraries, and not just yours.

If for whatever reason you hate the SLF4J API and using it will snuff the fun out of your work, then by all means go for j.u.l. After all, there are means to redirect j.u.l to SLF4J.

By the way, j.u.l parametrization is at least 10 times slower than SLF4J's which ends up making a noticeable difference.

IMHO, the main advantage in using a logging facade like slf4j is that you let the end-user of the library choose which concrete logging implementation he wants, rather than imposing your choice to the end user.

Maybe he has invested time and money in Log4j or LogBack (special formatters, appenders, etc.) and prefers continuing using Log4j or LogBack, rather than configuring jul. No problem: slf4j allows that. Is it a wise choice to use Log4j over jul? Maybe, maybe not. But you don't care. Let the end user choose what he prefers.

I started, like you I suspect, using JUL because it was the easiest one to get going immediately. Over the years, however, I have come to wish I had spent a little more time choosing.

My main issue now is that we have a substantial amount of 'library' code that is used in many applications and they all use JUL. Whenever I use these tools in a web-service type app the logging just disappears or goes somewhere unpredictable or strange.

Our solution was to add a facade to the library code that meant that the library log calls did not change but were dynamically redirected to whatever logging mechanism is available. When included in a POJO tool they are directed to JUL but when deployed as a web-app they are redirected to LogBack.

Our regret - of course - is that the library code does not use parameterised logging but this can now be retrofitted as and when needed.

We used slf4j to build the facade.

1. java.util.logging was introduced in Java 1.4. There were uses for logging before that. That's why many other logging APIs exist. Those APIs were used heavily before Java 1.4 and thus had a great market share that didn't just drop to zero when 1.4 was release.

2. JUL didn't start out all that great. Many of the things you mentioned were a lot worse in 1.4 and only got better in 1.5 (and I guess in 6 as well, but I'm not too sure).

3. JUL isn't well suited for multiple applications with different configurations in the same JVM (think multiple web applications that should not interact). Tomcat needs to jump through some hoops to get that working (effectively re-implementing JUL if I understood that correctly).

4. You can't always influence what logging framework your libraries use. Therefore using SLF4J (which is actually just a very thin API layer above other libraries) helps keep a somewhat consistent picture of the entire logging world (so you can decide the underlying logging framework while still having library logging in the same system).

5. Libraries can't easily change. If a previous version of a library used to use logging-library-X it can't easily switch to logging-library-Y (for example JUL), even if the latter is clearly superior. Any user of that library would need to learn the new logging framework and (at least) reconfigure their logging. That's a big no-no, especially when it brings no apparent gain to most people.

Having said all that I think JUL is at least a valid alternative to other logging frameworks these days.