Java Logging Vs Log4j

JUL : java.util.logging package

Similarities

• 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."
• 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.

Functionality Differences

They differ most in the areas of useful appender/handler implementations, useful formatter/layout implementations, and configuration flexibility.

1. Handler/Appender :
   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.

2. Formatter/Layout : 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.

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.

1. COnfiguration : 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. 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.

Q1. 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?
Q2. 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?
Q3. 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.

Source - http://java.sys-con.com/node/48541?page=0,0