Are your
Java programs littered with a multitude of randomly placed System.out.println statements and stack traces? When you add debugging messages to a class in a project, are the outputs of your messages interleaved among dozens of messages from other developers, making your messages difficult to read? Do you use a simple, hand-rolled logging API, and fear that it may not provide the flexibility and power that you need once your applications are in production? If you answered yes to any of the above questions, it's time for you to pick an industrial-strength logging API and start using it.
This article will help you choose a logging API by evaluating two of the most widely used Java logging libraries: the Apache Group's Log4j and the java.util.logging package (referred to as "JUL"). This article examines how each library approaches logging, evaluates their differences and similarities, and offers a few simple guidelines that will help you decide which library to choose.
Introduction to Log4j
Log4j is an open source logging library developed as a subproject of the Apache Software Foundation's Logging Services Project. Based on a logging library developed at IBM in the late 1990s, its first versions appeared in 1999. Log4j is widely used in the open source community, including by some big name projects such as JBoss and Hibernate.
Log4j's architecture is built around three main concepts: loggers, appenders, and layouts. These concepts allow developers to log messages according to their type and priority, and to control where messages end up and how they look when they get there. Loggers are objects that your applications first call on to initiate the logging of a message. When given a message to log, loggers generate Logging-Event objects to wrap the given message. The loggers then hand off the LoggingEvents to their associated appenders. Appenders send the information contained by the LoggingEvents to specified output destinations - for example, a ConsoleAppender will write the information to System.out, or a FileApppender will append it to a log file. Before sending LoggingEvent information to its final output target, some appenders use layouts to create a text representation of the information in a desired format. For example, Log4j includes an XMLLayout class that can be used to format LoggingEvents as strings of XML.
In Log4j, LoggingEvents are assigned a level that indicates their priority. The default levels in Log4j are (ordered from highest to lowest): OFF, FATAL, ERROR, WARN, INFO, DEBUG, and ALL. Loggers and appenders are also assigned a level, and will only execute logging requests that have a level that is equal to or greater than their own. For example, if an appender whose level is ERROR is asked to write out a LoggingEvent that has a level of WARN, the appender will not write out the given LogEvent.
All loggers in Log4j have a name. Log4j organizes logger instances in a tree structure according to their names the same way packages are organized in the Java language. As Log4j's documentation succinctly states: "A logger is said to be an ancestor of another logger if its name followed by a dot is a prefix of the descendant logger name. A logger is said to be a parent of a child logger if there are no ancestors between itself and the descendant logger." For example, a logger named "org.nrdc" is said to be the child of the "org" logger. The "org.nrdc.logging" logger is the child of the "org.nrdc" logger and the grandchild of the "org" logger. If a logger is not explicitly assigned a level, it uses the level of its closest ancestor that has been assigned a level. Loggers inherit appenders from their ancestors, although they can also be configured to use only appenders that are directly assigned to them.
When a logger is asked to log a message, it first checks that the level of the request is greater than or equal to its effective level. If so, it creates a LoggingEvent from the given message and passes the LoggingEvent to its appenders, which format it and send it to its output destinations.
Introduction to JUL
The java.util.logging package, which Sun introduced in 2002 with Java SDK version 1.4, came about as a result of JSR 47, Logging API Specification. JUL is extremely similar to Log4j - it more or less uses exactly the same concepts, but renames some of them. For example, appenders are "handlers," layouts are "formatters," and LoggingEvents are "LogRecords." Figure 1 summarizes Log4j and JUL names and concepts. JUL uses levels the same way that Log4J uses levels, although JUL has nine default levels instead of seven. JUL organizes loggers in a hierarchy the same way Log4j organizes its loggers, and JUL loggers inherit properties from their parent loggers in more or less the same way that Log4j loggers inherit properties from their parents. Concepts pretty much map one-to-one from Log4j to JUL; though the two libraries are different in subtle ways, any developer familiar with Log4j needs only to adjust his or her vocabulary to generally understand JUL.
Functionality Differences
While
Log4j and JUL are almost conceptually identical, they do differ in terms of functionality. Their difference can be summarized as, "Whatever JUL can do, Log4j can also do - and more." They differ most in the areas of useful appender/handler implementations, useful formatter/layout implementations, and configuration flexibility.
JUL contains four concrete handler implementations, while Log4j includes over a dozen appender implementations. JUL's handlers are adequate for basic logging - they allow you to write to a buffer, to a console, to a socket, and to a file. Log4j's appenders, on the other hand, probably cover every logging output destination that you could think of. They can write to an NT event log or a Unix syslog, or even send e-mail. Figure 2 provides a summary of JUL's handlers and Log4j's appenders.
JUL contains two formatter classes: the XMLFormatter and SimpleFormatter. Log4j includes the corresponding layouts: the XMLLayout and SimpleLayout. Log4j also offers the TTCCLayout, which formats LoggingEvents into content-rich strings, and the HTMLLayout, which formats LoggingEvents as an HTML table.
While the TTCCLayout and HTMLLayout are useful, Log4j really pulls ahead of JUL in the formatter/handler arena because of the PatternLayout. PatternLayout instances can be configured with an enormous amount of flexibility via string conversion patterns, similar to the conversion patterns used by the printf function in C. In PatternLayout conversion patterns, special conversion characters are used to specify the information included in layout's formatted output. For example, "%t" is used to specify the name of the thread that started the logging of the message; "%C" is used to specify the name of the class of the object that started the logging of the message; and "%m" specifies the message. "%t: %m" would result in output such as "main thread: This is my message." "%C - %t: %m" would result in output such as "org.nrdc.My-Class - main thread: This is my message." The Pattern-Layout is extremely useful, and JUL's two formatter classes don't come anywhere near to matching its versatility. It's not uncommon for JUL users to write their own custom formatter class, whereas most Log4j users generally need to just learn how to use PatternLayout conversion patterns.
While both Log4j and JUL can be configured with configuration files, Log4j allows for a broader range of configuration possibilities through configuration files than JUL does. JUL can be configured with .properties files, but until J2SE 5.0 the configuration of handlers was only on a per-class rather than a per-instance basis. This means that if you are going to be using a pre-Tiger SDK, you'll miss out on useful configuration options, such as the ability to set up different FileHandler instances to send their output to different files.
It's important to note that pre-Tiger JUL can easily be configured to write to multiple output files in code, just not through its default configuration mechanism. Log4j can be configured with .properties and/or XML files, and appenders can be configured on a per-instance basis. Also, Log4j allows developers to associate layout instances with appender instances, and configure layouts on a per-instance basis. This includes PatternLayout instances - you can set the conversion pattern each uses in the configuration file. During development, it usually isn't a problem to recompile an application to adjust its logging configuration; after deployment, however, you may want to be able to tweak or even completely reconfigure your application's logging without recompiling. In that case, Log4j offers more flexibility, especially pre-Tiger.
Log4j provides a lot of functionality that JUL lacks, although JUL is catching up. JUL could definitely be extended to do what Log4j does - you could write more handlers, reimplement the PatternLayout for JUL, and upgrade JUL's configuration mechanism, all without extreme difficulty. But why do that when Log4j has had those features for years?
Which Library Do You Choose?
Important decisions such as these typically make project leaders lose sleep and go prematurely gray. Luckily, this decision can be made very easily by examining the answers to three simple questions.
Question One
Do you anticipate a need for any of the clever handlers that Log4j has that JUL does not have, such as the SMTPHandler, NTEventLogHandler, or any of the very convenient FileHandlers?
Question Two
Do you see yourself wanting to frequently switch the format of your logging output? Will you need an easy, flexible way to do so? In other words, do you need Log4j's PatternLayout?
Question Three
Do you anticipate a definite need for the ability to change complex logging configurations in your applications, after they are compiled and deployed in a production environment? Does your configuration sound something like, "Severe messages from this class get sent via e-mail to the support guy; severe messages from a subset of classes get logged to a syslog deamon on our server; warning messages from another subset of classes get logged to a file on network drive A; and then all messages from everywhere get logged to a file on network drive B"? And do you see yourself tweaking it every couple of days?
If you can answer yes to any of the above questions, go with Log4j. If you answer a definite no to all of them, JUL will be more than adequate and it's conveniently already included in the SDK.
Conclusion
Log4j and JUL are very similar APIs. They differ conceptually only in small details, and in the end do more or less the same thing, except Log4j has more features that you may or may not need.
Keep in mind as you migrate to your chosen logging library that logging may affect the performance of your application. Make its impact as light as possible by reusing references to loggers; keep a static or instance pointer to loggers that you use, rather than calling Logger.getLogger("loggerName") every time you need a logger. Use common sense in your placement of log statements - do not place them in tight, heavily iterated loops.
