log4j vs. System.out.println - logger advantages?

Question

Hi!

I'm newly using log4j in a project. A fellow programmer told me that using System.out.println is considered bas style and that log4j is something like standard for logging matters nowadays.

We do lots of JUnit testing - System.out stuff turns out to be harder to test.

Therefore I began utilizing log4j for a Console controller class, that's just handling commandline parameters.

// some logger config 
org.apache.log4j.BasicConfigurator.configure();
Logger logger = LoggerFactory.getLogger(Console.class);
Category cat = Category.getRoot(); 

Seems to work:

logger.debug("String");

Produces:

1 [main] DEBUG project.prototype.controller.Console  - String

I got two questions regarding this:

1. From my basic understanding using this logger should provide me comfortable options to write a logfile with timestamps - instead of spamming the console - if debug mode is enabled at the logger?
2. Why is System.out.println harder to test? I searched stackoverflow and found a testing recipe. So I wonder what kind of advantage I really get by using log4j.

Answer 1

1. use e.g.

   org.apache.log4j.BasicConfigurator.configure(new FileAppender(
     new PatternLayout("%d{ISO8601} %-5p %t: %m%n"), // see e.g. http://en.wikipedia.org/wiki/Log4j#TTCC
     "log/mainWhatever.log"));

2. Using logger.setLevel(...) you can easily choose whether to display logger.debug(..) messages, e.g. set it to level warn and any trace, debug and info statements will not be printed. This saves you the time of having to comment out only occasionally needed debug statements.

Also have a look at Wikipedia.

Answer 2

The logger gives to ability to define different levels of importance of the logged messages and the ability to use different sink for the output - the console, a file, etc.

Also it's easy to enable or disable only some type of message when using a logger - for example you don't want to see every debug message in production.

I don't think that using loggers offers any significant advantages in unit tests, but I'd prefer it even there anyways. In unit tests asserts are usually my primary concern.

Btw you should really consider using something like Commons Logging or SLF4J as a log framework facade - it's bad style to tie your code to a specific logging framework. Common Logging and SLF4J make it easy to switch logging frameworks if you choose to.

Answer 3

Anything that you print to System.out will go to "standard out", and while you can redirect standard out to a file and compare it, what have you, that is very inflexible. Additionally, you cannot filter what goes to standard out if you use System.out... everything will be printed. With log4j, you can set different logging levels, so that logging messages that are below a certain severity/importance threshold are not printed (e.g. if you change the logging level to WARN, then DEBUG and INFO messages will not be displayed anymore).

Additionally, log4j allows logging to be controlled on a class-by-class basis, whereas System.out can only be controlled at the granularity of the entire application (if you redirect System.out, you redirect it for the entire program). By contrast, each logger in log4j can be given a different appender. In addition, you can give a log4j logger multiple appenders (so that it goes the system logger, and over the network, for example). You can even have a log4j logger append to a StringBuilder, so that you can easily read what was written. And while System.out can be redirected, this redirection tends to be fairly limited; System.out can be redirected to a file or to a pipe (to another program), but you wouldn't be able to redirect it to a URL, for example; by contrast, it would be very easy to create an appender that transmits logging messages using HTTP POST.