JDK logging really does suck

So I’d been trying out JDK logging for the last few months for a couple of projects, and I had been getting annoyed with two problems:

1. There were no nice convenience methods on Logger, such as warn(String, Throwable).
2. In getting around the first issue (by creating a wrapper Logger), everything gets reported in my logs are coming from my wrapped logger class!

I had assumed that this was just an error on my part and made a mental note to check in to it soon. But apparently I’m not the only one having this problem. On JavaBlogs, I found this blog entry describing the exact same issues:

Sometimes it’s nice to review the libraries being used and re-evaluate their value. This is especially useful when some code was written for Java 1.2 and is now being used on 1.5. log4j was handy in ‘99, but Java 1.4 added java.util.logging. In the recent past, I’ve continued to use log4j mostly because it’s much easier to configure than java.util.logging. That’s a pretty silly reason and can be fixed with a little code, so I decided to give log4j the old heave ho. Well, I quickly found out that java.util.logging’s Logger is not as easy to use as log4j. java.util.logging expects you to type “logger.log(Level.INFO, message)” while in log4j it’s just “logger.info(message).” Plus, there isn’t a “isInfoEnabled()” method. There are many other convenience methods missing. This RFE from 2001, lists the problems. I quickly created a JvLogger class that extends Logger and adds the convenience methods. That didn’t work because the java.util.logging.LogRecord class scans through the stack trace entries to find out who called the log() method. Using JvLogger, it’s always JvLogger that calls log(). The problem is documented in this bug, also from 2001. It’s surprising that after all these years that something as simple as a logging API is still broken.

Amazing that Sun hasn’t addressed this issues. Looks like its back to log4j!