Logging in Clojure / JVM – Part 1

Ok this title is little misleading. This blog post is not just about logging in clojure (or the JVM), but also about the whole amazing world of log management and analysis. I am working on this side project during nights and weekends. Since it’s a green-field project, I wanted to get logging right. Ater all, at the end of all my past projects , I always came to the conclusion that I could have done logging better. It isn’t just me, but even when I speak with other software developers they also feel that logging could use more attention. This is my attempt to help myself and in the process help others get logging right.

Logging library in clojure:

It is a very simple ecosystem. We have clojure/tools.logging. It is a set of logging macros that delegates to specific logging implementations. OK, and what does specific logging implementation mean? To understand this better, we need to understand the logging ecosystem in Java.

History of logging in Java:

Log4J was the first well known java logging library. In fact, it is still used in many projects. It’s probably the most popular.

When Sun realized that logging is important, instead of incorporating log4j, they went ahead and created another logging framework. It was called JUL (short form for java.utils.logging). Honestly, I do not see any benefit of using JUL over log4j. They probably went “hey, log4j wasn’t invented here, so lets create something else to do the same thing”. So that pretty much created the first split between java libraries where some were using log4j and some were using JUL. Already, it started getting difficult to make different libraries work together.

As libraries should not impose the use of a particular logging implementation, another project created called Commons Logging came to be. It was advertised as an ultra thin bridge between different logging implementations. So a library using commons logging could change the logging implementation (log4j or JUL ) at runtime. It used class-loader magic and dynamic binding to load specific logging implementations. Of course, it became complex to debug issues. In the end, it created more problems than it solved, and people were not particularly happy about commons logging.

So the creator of Log4j, Ceki Gulcu, created a logging facade called SL4j (short form for “Simple Logging Facade for Java”). SLF4J, unlike commons logging is an API, which allows end users to plug-in their desired logging system at deployment time. It does not have any class-loader magic or dynamic binding like commons loggings. SLF4J binding is hardwired at compile time to use a specific framework. As slf4j is an API, it needed an adapter layer on top of log4j, JUL and commons logging. SLF4J already comes with adaptor layers for commonly used logging frameworks.


[image from http://www.slf4j.org/manual.html]

Ceki Gulcu also felt it was time to improve log4j. So he created logback. You can go through the reasons to switch from log4j (or JUL) to logback. For now logback is considered the best logging implementation we have for the JVM. The best part of logback is it natively implements SLF4J API. So we do not need any slf4j adaptor layer to use logback with slf4j.

Now that we have seen the logging ecosystem in JVM, in the next part of this series, we’ll take a look some more at SLF4J.

2 thoughts on “Logging in Clojure / JVM – Part 1

  1. > They probably went “hey, log4j wasn’t invented here, so lets create something else to do the same thing”.

    That’s a fairly accurate description of what happened. Sun created the java.util.logging package at a time when log4j was already well established. There was some tension between Sun and IBM back then (how times change) and Sun seemed threatened by how seriously IBM was driving Java forward. Log4j was definitely associated with IBM because it came out of an IBM project and was released as open-source under IBM’s developerWorks banner.

    When Sun announced a new logging framework would be part of the standard JDK 1.4, Ceki started a petition to have log4j incorporated rather than the proposed system which was virtually identical apart from the direction of inheritance with loggers. Ceki’s campaign attracted many signatures (including mine) and eventually a compromise was reached whereby java.util.logging would adopt the same inheritance direction as log4j to keep them compatible, and Ceki renamed Category to Logger to help align the two.

    The official reason given by Sun for why log4j couldn’t been incorporated ‘as-is’ into the JDK was that there wasn’t time to do so before their internal deadline for the ‘Merlin’ release of the JDK (1.4), which seems a poor excuse today, especially given the countless hours of developer time that has been wasted as a consequence.

    All this is historical and academic now, but it serves as a good example of why platforms like Java tend to be better served when they are managed by developers themselves rather than by corporations, even benevolent ones.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s