The main function of a good logging implementation is to provide a clear overview of the functioning of a system. Basically, the logging must describe the inner workings of a system and provide the necessary details to the readers of the log. In fact, good logging can drastically reduce maintenance costs of your applications, especially for clustered systems.

Logging is a crucial part of every system and provides all the information about the state of a system. The key is to provide this information without cluttering the code too much with these logging statements.

Most programmers tend to use a decent logging mechanism in their applications, but few of them use it elegantly. How can we make sure that we don’t clutter our code with unnecessary statements that reduce readability?

The worst type of logging is, of course, the usage of System.out.println’s in your code. You will have no fine grained control over your log statements and all statements will be directly written to the standard output. Stop this madness and use a proper logging mechanism! No excuse will be good enough! Really, I’m not kidding here..

Log4j to the rescue?
Most developers noticed this issue and started to use a decent logging mechanism, like Log4j, taking control over their log statements. The main problem is that developers could decrease performance of the system by not using the log API correctly (e.g. concatenating all strings in the log statement, even when the log statement is disabled). It would be better to not use any expensive operations in your log statements, of course, but that’s not really a real option.

Be aware that the log level could be inactive in some cases (e.g. debug logging should not be enabled in a production environment) and that you make proper use of the log categories.

What you could do is checking the log level before putting in some expensive operations. The point of isDebugEnabled() is to save loops and temporary object creation for debug purposes, when you have no need for the debug log. But you will eventually create more clutter in your code when you’ll use this statement all over the place.

Don’t clutter your code with isDebugEnabled statements when you’ve other options to use! You can avoid this cluttering by simply making use of the standard Java JDK 5.0 String formatting feature or by using a more advanced approach with the slf4j logging abstraction.

The solution
We can enhance our code base with proper log statement and minimal overhead by using slf4j. The slf4j framework can be used as a simple abstraction on many logging systems and therefore provide some nice mechanisms to improve your code base.

Slf4j can be used by specifying the slf4j logger in your code:
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
...
Logger logger = LoggerFactory.getLogger(ClassToBeLogged.class);

Log4J with the isDebugEnabled check
if (logger.isDebugEnabled()) {
  logger.debug("The size is '" + list.size() +
    "', for '" + user.getUsername() + "'.");
}


SLF4J logging
logger.debug("The size is '{}', for '{}'.", list.size(), user.getName());

JDK 5.0 logging
logger.log(Level.FINE, "The size is '{0}', for '{1}'.", new Object[]{list.size(), user.getName()});

Which statement do you prefer?
Note that this is even the most simple example that I could come up with.

I’m aware that the Java JIT compiler is intelligent enough to optimize some of your code in certain cases so that operations will be optimized before the real execution of the application. E.g. the following two statements will produce the exact same byte code:

log.debug("Start of debug logging.");
and
log.debug("Start " + "of " + "debug " + "logging " + ".");

But it is nevertheless better to watch out and don’t do anything stupid!