Performance and Functioanlity Difference between log4j and Logging Util class

Question

I am newbie for the logging class in Java.util package, I have developed an Application and want to implement the logging mechanism at different levels, I am just thinking to which one to go for and identify the differences between these 2. I am looking 1) logger should be easily maintainable, implementable. Can any one suggest on this.

Answer 1

java.util.logging is a poor API, on top of a poor implemention. Log4j is better in every measurable way.

If it's a new development, though, then there are better APIs than log4j, such as SLF4J, and better logging implementations, such as Logback. I would try those. Log4j is getting a bit long in the tooth, but it's perfectly serviceable.

Answer 2

Check out the Functionality differences Between Log4j and Java.util.Logging Package

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.

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.