May 27, 2010

Java Logging Frameworks Must Die

Last week I performed a release of some client software, the change was small and discrete: a move from Torque v3.2 to Torque v3.3, and a small database schema change. That was it.

Then I get the call: their archive isn't working, can I investigate. Their archive is a web application frontend to an IMAP server storing archived email data. Simple, effective, and as of last week, broken.

Dig, dig, Google, dig.

Eventually I find the culprit: Torque was depending on an obscure logging framework, which was in turn depending transitively on an obscure incomplete implementation of javamail called geronimo-spec-javamail. This was pulled in alongside javamail as shipped by Sun.

Two competing incompatible implementations of javamail in the same application in the world of Java == fail.

Fast forward a week. Another application that is up and running fine is suddenly reported as not working. All the application does is create an email with a velocity template, and send the mail. That's it. But Velocity depends transitively on an obscure logging framework, which recently decided for no clear reason would not longer work from within a web application.

When you spend more time tracking down obscure sudden failure cases than you do producing actual code, you know you've reached the tipping point of failure.

Java logging frameworks must die.

Continue reading "Java Logging Frameworks Must Die" »

Creative Commons License
This weblog is licensed under a Creative Commons License.
Powered by
Movable Type 3.21