by Steven J. Owens (unless otherwise attributed)
I did a little looking into the JDK 1.4 logging API. Nothing special in the API itself, it reminds me a lot of the log4j API http://jakarta.apache.org/log4j/docs/manual.html), with a few trivial differences.
Given that the APIs are extremely similar, I'm torn between wanting to adopt the imminent "blessed" standard (JDK 1.4) and adopting the defacto standard (log4j). My conclusion is that it won't make much difference either way. But, since we have to download a separate logging API anyway, why not go with the one that is open source, is in common use and has more support available, which would be log4j.
When I looked at the log4j API it was just after we'd developed a set of logging classes at my previous company, so I was looking for some good reason to move to the log4j API. I didn't see anything especially impressive at the time. On the other hand, a year later there are more adaptors and add-ons for log4j; still nothing earth-shattering, but some good solid work. This reinforces my conclusion (at the bottom of this page) that using any logging API is more than half the battle.
The basic layout of both APIs is the same:
JDK 1.4 log4j Description
loggers categories structural organization of log messages levels priorities importance organization of log messages handlers appenders determines which messages to listen to formatters layouts formats output of log messages
The loggers/categories objects are a hierarchy of categories configured with dot-separated name Strings, much the same way java packages are named. They provide a dimension of organization that is orthogonal to the levels/priorities. This dimension can be anything really but is assumed to usually be based on the structure of the program (e.g. package names, etc).
The loggers/categories are instantiated as a tree of objects, which are then accessed via a singleton root manager.
The jdk1.4 logging API also provides support for anonymous loggers, i.e. loggers that are not part of the singleton-managed tree. The author of log4j dismisses this as not particularly useful.
The levels/priorities are pretty much what you'd assume, numeric values with associated descriptive names to indicate the importance of the log message.
The handlers/appenders provide multiplexing and filtering of log messages and deliver the messages to different outputs.
The log4j project reportedly has a greater variety of appenders with support for logging to console, files, GUI components, remote socket servers, jms messages, NT event loggers and remote unix syslog daemons, and asynchronous logging.
The JDK 1.4 logging api provides a console, output stream, file, remote sockets, and in-memory handler (the in-memory handler looks like it provides asynchronous logging, i.e. when the buffer fills up it dispatches the messages to another handler, presumably a file handler or something).
One thing I've wondered repeatedly is why nobody has developed a logging API based on java's event model.
One interesting looking bit for the JDK 1.4 logging API is that, if called without class/method arguments, it will try to guess which class and method the log came from. On the other hand, this is not reliable, especially with optimizing compilers, etc.
There's absolutely nothing on sun's site about logging support for earlier JDKs, however the "Lumberjack" project is a clean-room, open-source implementation of the API for use with earlier APIs.http://javalogging.sourceforge.net/
The principal author of log4j has some criticisms of the logging API. His more serious earlier criticisms have mostly been addressed in the most recent draft of log4J but he still has some issues:http://jakarta.apache.org/log4j/docs/critique2.html (supersedes the previous critique at http://jakarta.apache.org/log4j/docs/critique.html).
One point to consider for people working with application servers (and possibly servlet engines, though less so) is that if and when their application server provider decides to do anything fancy with logging APIs, they will likely do it with the JDK 1.4 logging API.
On the other hand, one of the more cogent criticisms of the JDK 1.4 logging API is that it doesn't support - nor intend to support - any sort of remote or distributed logging.
The Zoo LV2 logging API looks like a candidate in that direction ( http://www.swzoo.org/log2/documents/intro.html). In particular, while LV2 appears to be significantly more complex (though their docs claim to have a gentle slope intro) it includes JINI support.
Overall, the most important thing is to create a logging structure and start using it - the cost of switching to a new logging scheme at a later date is likely to be a lot less than the cost of switching from System.out.println() calls. We ended up deciding to go with log4j.