Imagine a bacon-wrapped Ferrari. Still not better than our free technical reports.

The State of Logging in Java 2013


Screen Shot 2013-08-01 at 12.04.44 PM

I was thinking recently about logging in Java, and how there are numerous logging frameworks (maybe even too many?) that can help you with this. Now, you’re not obliged to use a framework, and even though Java’s standard code base includes logging almost nobody seems to use it. Most developers lean towards using an external framework to help them log information at runtime.

For a beginner it might be confusing and if not taught right, you’ll most likely use System.out.print. As with a lot of other Java frameworks, logging frameworks exist in order to fill a gap in Java’s core. That’s how we end up with a couple of different choices, which I can imagine for a newcomer is not easy find the right tree in the woods of logging frameworks.

Inspired by other Java tool surveys, I was interested in finding what other devs like to use, whether they’ve even considered or heard of alternatives, and if they even use logging at all. I created a small survey and put it on my blog. Although just 110 people responded, it was a diverse enough subset with responses coming from the US, Europe, Asia, Africa and South America. The average age was 35 with a standard deviation of 7 years: the youngest response being entered by a 22-year-old and the oldest by someone 63 years young. About 60% of them are developers, 30% architects.


Quick review of why we use logging…

Many of you already know this, but logging is just a way of monitoring your application, and when used right this can provide you with information of what is happening during you’re application’s runtime process.

You can log errors and actions your applications encounter, which is pretty critical to me unless you never write any bugs. Don’t say it! Logging other things can be very informative e.g. the start and end of a batch process, the changes made by administrators, amount of processed files, duration within a certain method call and so on.

It’s kind of a double-edged sword. You want the right kinds of information available to you, but don’t want to store tons of old logs that don’t mean anything to you a year later. You want to try to write concise informative messages that are self-explanatory and able to be dumped soon after, as needed.

To close off this quick review, here are some of my opinions if you care to read them:

  • ERROR label for actual errors!
  • WARN for potential issues that can interfere with correct workings of the application but will not crash it. (e.g. a 3rd party back up storage system that could not be reached, but will be retried.)
  • INFO for messages announcing the start of your batch process.
  • DEBUG and TRACE for all other things you don’t want to read in the future or only when really needed, like the type of implementations of certain interfaces loaded on startup. I believe if you are using the DEBUG or TRACE level to actually debug your application, you probably should have written a unit test that verifies that part of code you wrote full with debug statements.

Let’s see the results of the survey!

Q: What are you using for logging in your Java Applications?



One thing is sure, System.out.println is practically banned from our world! Less than 2% of the respondents are still using it. And perhaps after this they will stop using it altogether.

From the remaining 98% majority, about 70% are using an abstraction framework like slf4j or commons logging, with slf4j being the grand winner with 61%. Around 28% use nothing.

Q: Which Framework do you use for Logging?

As for the actual logging framework Log4j (52%) remains the most widely used logger, with Logback (29%) on it’s tail. It may surprise you that 7% of the people that use a logger actually write the logging framework themselves.  That’s about the same amount that use jul (java.util.logging). JBoss logging, the logging framework that is used in almost anything that is build at RedHat or JBoss, only has a market  share of 1%.


Q: What level is logged and how is it logged?

The majority of people (70%) write logging statements in their application to print out informational and error statements.  Only 1% claims to only write logging calls for only errors while another 10% is in love with logging and would try to log as much as they can. The remainders aren’t really sure, they do other things.

The most used levels of logging are ERROR, INFO and yes DEBUG. It seems that WARN and TRACE aren’t really popular.

When it comes to the actual statements that are logged, the majority (40%) claims to write log statements like:

LOG.debug("Hey, we're adding " + entity.toString() + " to the database now! It has id " + entity.getId())

And even in this case, I hope you are using Java 6 or higher, since any compiler before that will not convert String concatenations to a StringBuffer version and it would impact runtime performance.

The second most popular is LOG.debug("Hey, we're adding {0} to the database now! It has id {1}", entity, entity.getId()), which is a good thing since it leverages the capabilities of the logging framework, such as with most slf4j implementations where it will not create the actual logged String unless the logging level is enabled to save your applications some processor instructions.

Furthermore, 23%  of respondents wrap their logging statements with an “if” where they check if the called logging level is enabled or not. But when it comes to actually enabling these levels, it’s another story.

Q: How about configuration?

Thirty-percent (30%) of respondents have only one configuration for all environments and the most-used lowest activated level seems to be INFO. I just  hope that this isn’t because they don’t have different environments for ‘dev’, ‘test’, ‘stage’, ‘production’….but let’s not go into that now.

The other 70% of respondents has multiple configurations, depending on in which environment the application is running. I found the following logs are the most popular by environment:

  • Production environment – ERROR to WARNING
  • Staging environment – INFO
  • Development & Testing environments – DEBUG 


Q: How do you collect log files?

Collecting the log files is mainly a manual thing, with 65% claiming to manually collect the files from their servers. Only 10% use self-hosted collectors like Scribe, Logstash or a database, and just 3% use cloud solutions like Sumologic or Logly. Another 22% isn’t involved in collecting their log files, let’s hope their Ops team is a DevOps team and doesn’t collect them manually ;-)


On the question of ‘what would you change?’

If one thing came clear from this open question, it is that the respondents find that there are too many ‘standards’ and that there should be only one. Namely: Replace JDK logging with SLF4J as a real Java Spec and stop the changes!

Another recurring request was to integrate AOP in to logging frameworks. And a nice comment came from a student: “I don’t know what to use. Why are there so many logging frameworks? Isn’t there a standard?”. This perhaps reflects the need for a review and standardization of java.util.logging.

General Conclusions

Slf4j seems to be the standard for most of us when it comes to using an abstraction layer that helps you log things from all the different frameworks that you use, and for logging in your own application.

For the actual logging framework Apache Log4j is the most used with Logback right on it’s tail. Which is a good thing for Logback that is really the successor of Log4j.

The most used logging levels are ERROR, WARN and DEBUG. And usually DEBUG is not enabled in a production environment.

Collecting the logs from servers seems to be a manual task for the majority of the respondents, so for you DevOps people out there, we have some work to do!

In the end, some believe there should be just a single standard built in as a Java standard.

Do you think this is all wrong?

Why not provide your own answers to the survey? I’d love to hit 500 respondents and get a really good cross-section of developers and architects involved. Just click below to share your practices!

Share your thoughts too

Please do leave comments below or reach out to me at @redlabbe or @ZeroTurnaround.