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.

This article is not an in-depth tutorial on how to use Log4j or JUL, and, in fact, has glossed over a number of useful features in both libraries, such as MBean support (in J2SE 5.0, you'll be able to set JUL logging levels remotely using JMX), and ResourceBundle support. There are also a number of advanced features that only Log4j has, such as filter chaining and Object-Renderers. The Internet is full of great tutorials on how to use both libraries, including a number of articles in JDJ's archives; be sure to check them out before you begin coding.

Resources

• Figure 1
• Figure 2