Logger facade that supports printf style message format for both performance and ease of use.

http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/Logger.html

The log5j package supports a 'modernized' interface on top of the class Log4j API usage.

It provides a few syntactic extensions thanks to JDK 1.5 (hence the name log5j).

Usage

First. It is no longer required to give the category when creating a new class level logger. Log5j just figures it out from the call stack.

For example old usage for log4j was:

private static final Logger log = Logger.getLogger( FeedTask.class );

and the new syntax with Log5j:

private static final Logger log = Logger.getLogger();

Much better and fixes a lot of copy/paste errors.

Note: There is still an option to provide a required category manually.

Second. It provides printf support for logging messages

Before:

log.debug( "This thing broke: " + foo + " due to bar: " + bar + " on this thing: " + car );

After:

log.debug( "This thing broke: %s due to bar: %s on this thing: %s", foo, bar, car );

That is SOOOOOO much better. Good god!

Note: By default java.util.Formatter syntax is used (http://java.sun.com/j2se/1.5.0/docs/api/java/util/Formatter.html).

New interfaces

Since version 2 there is a new way to use the log which could be more appropriate, but in the end it's a matter of taste.

Getting log object example:

  private static final Log log = LogFactory.getLog();

Usage example:

  try {
    // do something
    log.d("Success! Parameters f=$.10f and i=%d", f, i);
  } catch (Exception e) {
    log.e(e, "Failure! Parameters f=$.10f and i=%d", f, i);
    // note: exception passed first separate from parameters
  }

Initialization

Appenders could have some non-daemon threads (for example, TelnetAppender), and it's actually correct because you usually don't want to lose messages during shutdown. Log4j provides a special method LogManager.shutdown() which should be called in the end of the shutdown routine to destroy appenders explicitly.

Log5j provides a similar method, but by default it's not necessary to call it in case you are Ok with possibility to lose messages in the end. If you can control initialization and shutdown phases of your application then the following methods should be called:

  // initialization phase
  com.spinn3r.log5j.LogManager.enableExplicitShutdown();

  ...

  // in the very end of the shutdown routine
  com.spinn3r.log5j.LogManager.shutdown();

Performance

There's also a performance advantage here.

If you were using debug calls with string concat the strings are CONSTANTLY generated even if the debug level is disabled. This burns CPU and pollutes your heap leading to addition garbage collection.

Now internally the debug message isn't even called and the string is never expanded/formatted unless the debug level is enabled.

Asynchronous logging

Log4j behaves pretty badly in a highly concurrent environment, and Log5j fixes this by logging messages asynchronously.

  private static final Log log = LogFactory.getLog(); // asynchronous by default

If you need a synchronous log then pass false to the factory method:

  private static final Log log = LogFactory.getLog(false); // synchronous