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.

  • grobmeier

    You are wrong by one thing: the successor of log4j 1 is log4j 2 with an very active and passionated team! Please see for more details. Feel free to ping me if you have any questions.

  • Ivan Averyanov

    Your are right! Logback is successor to the log4j really.
    “Logback is intended as a successor to the popular log4j project, picking up where log4j leaves off.”

    Ceki Gülcü is author of log4j and next logback.
    From linkedIn: “Expertise in developing java applications. Founder and maintainer of several open source projects such as log4j, slf4j and logback.”

  • grobmeier

    Many people have worked hard on log4j 1.x and not only Ceki. It is unfair and not accurate to attribute all success of log4j to only one person.

    Log4j is still actively developed and maintained by > 6 persons and released 8 version so far. Ceki decided to fork to Logback in 2005 and is not longer actively working on log4j. It means a single person from a project did have a different vision than the rest of the project but you can’t say that all efforts on log4j are lost just because one person left.

    The “reasons to switch” page you are referencing to is outdated. It’s using log4j 1.x as example. Please compare a recent version of logback to a recent version of log4j, like on this page (bottom):

    The current version of log4j is 2.x.

    It is not even true that Ceki is THE founder of log4j. He is ONE of the founders as can be seen here:

    One of 6 persons.

  • Ivan Averyanov

    Thanks you for the clarification!
    I’m sorry if I offended you.

  • grobmeier

    No problem! And no, you didn’t offend me, sorry if it sounded like that.

  • balder

    You are right, I should have differentiated between log4j-1.x and log4j2 in my questions!

    I personally haven’t tried out log4j2 nor have I been in contact with it yet, but I will give it a go to compare it with logback.

    I stated that it’s the successor since it’s becoming more and more popular lately amongst people I meet. But perhaps all those people also haven’t tried log4j2.

  • mmbravo

    “Any sufficiently complex Java program will transitively depend on every logging implementation ever.”

    Why did you guys feel the need to write yet ANOTHER logging library, instead of trying to patch what you guys felt was wrong with logback?

  • grobmeier

    Because it was not possible to work on Logback and even if, it would not give me the guarantees I need.

    At Apache we work in a community. Means, we discuss things until we have a consensus. Everybody has a voice.

    Logback ppl are known to work different. In fact, it is almost impossible to have a change arriving at Logback if QOS (the company behind logback) doesn’t allow it. To my knowledge it has been tried to patch Logback with a few changes we have now done in Log4j but they were rejected. You could say, if QOS is at vacation, no patches will get applied. For me, this development model is not acceptable. Others like the “benevolent dictator” model in software development.

    If you look at Logbacks GitHub repository you’ll see there were contributions from many people over the years. Actually most of them just contributed one time or so. Only one person besides the maintainer seems to have contributed more.
    At Log4j we have currently 6 persons contributing regularly to Log4j 2. For me that is a clear signal that a more open model is more appreciated in open source. Of course, that point of interpretation.

    An issue is that Logback has some flaws in architecture which cannot be fixed easily. It would need a lot of work to fix it and given the development model it might be very difficult to argue on the changes.

    Logging is existential to me. I prefer a community build framework which is protected by an open source foundation (like Eclipse or Apache). Software foundations are here to protect the developer and the user in me. I have no idea on the plans of a company like QOS and besides promises no guarantee. If you want to rely on promises you are good to go. I have learned not rely on promises from a company from Oracle.

    Besides, we did not create ANOTHER logging framework but created a new and modern version of log4j 1. Lot has been rewritten, that’s true. Still its “just” a version 2 as it happens with a lot of frameworks. Logging cannot be backwards compatible for all ages; as with every framework it needs to evolve as the language/environment evolves. Please don’t expect Logback to stick with its version number. At one day they will start to work on a different version too (guessing).

    In fact, the creators of Logback had the chance to contribute their changes to log4j back in 2005. They are still listed as project members on log4j.
    They decided to fork. Actually the Logback maintainer was not happy with the development model of the ASF (everybody has a voice). Instead he once proposed “Commitocracy” (the voice of the guy who contributed most has the most weight). You need to decide what you like more.
    Please note, I applaud the Logback developers for their work and I welcome them back on the log4j project, as it seems to me that many problems of the past were resolved.

    To sum it up, working on Log4j 2 gives me:

    – independence from a company
    – a voice on decisions
    – protection by a Software Foundation
    – a big Logging community
    – a huge community inside the ASF.

    A couple of ASF projects already discuss to move on to Log4j 2. They will of course contribute back if there are flaws and this will even make the community bigger. Among projects who consider or already decided on using Log4j 2 were Apache Struts, Apache Onami and Apache Syncope.

    With that in mind I feel Log4j 2 has a bright future.

    Now there is just one thing left to fix: people are using slf4j as facade. While this is the best facade available at the moment, it is still maintained by a company. I suggest to fix this issue by supporting a new logging JSR. A facade inside the JDK will address many issues, even when it comes what engine you use.

    There is already some movement, please see here:

    This is all my personal opinion and impression of course. At log4j others might have different opinions and reasons to contribute to Log4j 2.

  • Kyriakos Vamvakaris

    Hi Guys,

    just to pass over the passionate discussion about which framework is the successor of which framework, I would like to point out that that the usefulness of this survey heavily depends on the quality of its user base.

    Is there any information where these users are coming from? Because 110 participants looks quite low to me to draw any conclusions. Just imagine if some of these users are working in the same project, to say the least….

  • balder

    Yes 110 is not enough, I know. The geographical spread was quite diverse but most respondents from Europe, USA and India. I would have to recheck the numbers to give an accurate number.
    I’d love to get more answers and do a follow-up write up!

  • balder

    A logging facadespec as JSR I would love that! And with me many others, I assume.

  • Noumenon72

    I don’t understand this sentence:
    “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.”
    How can debug statements in my unit test tell me anything? Don’t they need to be in the actual code I’m running?

  • 4lberto

    IMHO this means that you should debug that part of code in a unit test, not running it with the whole application. Using a log framework with debug level messages is a technique of debug and use an specific unit test is another. He is not referring to use log inside the test