Is Standard Java Logging Dead? Log4j vs. Log4j2 vs. Logback vs. java.util.logging

Capitalized log levels induce high levels of stress. What if, instead of ERROR we’d just use “oops”? On a more serious note, we’ve recently ran a huge data crunch over GitHub’s top Java projects and the logging statements they use, revealing the log level breakdown of the average Java project.

In this post, we’ll explore the resulting data set from another angle, shed some more light on the dataset, and put the focus on the use of standard java.util.logging levels versus more popular frameworks like Log4j (+ Log4j 2), and Logback.

Step right in.

Meet The Players

Logging utilities can be roughly divided to 2 categories: the logging facade and the logging engine.

As far as logging facades go, you pretty much have 2 choices: slf4j and Apache’s commons-logging. In practice, 4 out of 5 Java projects choose to go with slf4j. Based on data from the top Java libraries in 2016 on Github. The motivation for using a logging facade is pretty definitive and straightforward, an abstraction on top of your logging engine of choice – allowing you to replace it without changing the actual code and logging statements.

As to the logging engine, the most popular picks are Logback, which is an evolved version of Log4j, Log4j itself, and its new version since the development was passed on to the Apache Software Foundation, Log4j2. Trailing behind is Java’s default logging engine, java.util.logging aka JUL.

Pointing Fingers And Calling Names

On the “superficial” side of things, each of the logging frameworks has slightly different names for their logging levels.

In the rare case where slf4j is used with java.util.logging, the following mapping takes place:

FINEST -> TRACE

FINER -> DEBUG

FINE -> DEBUG

INFO -> INFO

WARNING -> WARN

SEVERE -> ERROR

Another thing to notice here is that Logback and java.util.logging have no FATAL equivalent. Behind those error names, are simple integer values, that help control the logging level in a running applications. Each library also contains values for OFF and ALL, which basically set the logger level to actually transmit everything, or nothing. Setting a logger level at WARN for instance, would only log WARN messages and above – Its practically the default setting for production environments.

How Does The Level Naming Breakdown Look In Practice?

For the data crunch, we focused on the top starred Java projects with at least 100 logging statements in either of the methods. Examining the data set of projects, here’s we found only 4.4% of projects exclusively used the java.util.logging naming scheme.

To look at the average java.util.logging project, we filtered it down to include only projects who had at least 100 statements from levels that don’t overlap with the non-JUL naming scheme (WARNING and INFO).

With that said, it looks like in both situations, roughly ⅔ of logging statements are disabled in production, since only WARN and above are activated in that case.

Fun fact: As an extra datapoint, we also looked at ALL / OFF levels. Turns out only 8.6% of the projects examined used them both.

How Did We Reach The Data?

The starting point for this research is the GitHub archive, and its datasets on Google BigQuery. We wanted to focus on qualified Java projects, excluding android, sample projects, and simple testers. A natural choice was to look at the most starred projects, taking in the database of the top 400,000 repositories.

We ended up with 15,797 repositories with Java source files, 4% of the initial dataset. But it didn’t stop there. Looking at the number of logging statements, we decided to only focus on projects with at least 100 different statements. The dataset is available right here.

We believe this to be a fairly representative sample of what we were trying to achieve. For the full walkthrough and the steps we took to reach the data, including the exact SQL queries, check out the last part in this post.

Final Thoughts

This post stresses out that java.util.logging is, well, practically dead. Most serious projects choose to go with 3rd party logging frameworks. Did you find anything else that we might have missed in the dataset? Do you have other interesting questions that can be answered through this or similar data?