Question

I’m using log4j for the first time in a project. A fellow programmer told me that using System.out.println is considered a bad 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 command-line parameters.

// log4j 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

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.