Forget cloud standardisation – we need a Logging API in Java
Java EE needs to turn the tide somehow with cloud features dissipating. How about standardising logging says Antonio Goncalves
The past few weeks have been tumultuous for
Oracle and Java EE. Not long after the much-talked about Jigsaw
incident, Java’s steward made it known that the PaaS specs targeted
for Java EE 7 were likely to move further down the
As the promised features dissipate, it doesn’t exactly help Oracle’s standing with enterprises or the community, despite the latter undoubtedly being the correct decision. It also raises questions over whether they are really tackling the important aspects for Java.
One man who thinks talk of cloud standardisation and multi-tenancy has distracted us from the real Java issues is Paris JUG co-leader Antonio Goncalves. In a blogpost, the Java EE 7 Expert Group Member brought up an incredibly important issue that has been overlooked – logging.
Goncalves argues that with so many logging frameworks now available, isn’t it now time to consider standardising a Logging API in Java? After all, the decision to lump cloud in Java EE 7 happened as the market is still very much in flux.
Logging has been one of Java’s weak points for a decade or more now, and has been continually causing issues for development teams, mainly because of how sluggish the process can be. Just by the sheer number of alternatives that have arisen, java.util.logging has become nigh on redundant. Apache’s Log4j has become the optimal choice for developers but there’s a myriad of options – Commons Logging, SLF4J, Logback and TinyLog are all popular enough.
Few months ago I was struggling (again) with logging configuration in JBoss 7.x. I was so depressed that I wrote to the Java EE 7 expert group : Logs. Should we finally do something? (you should read it, there are valuable opinions expressed by the members). As a developer I’ve used all the possible logging Java frameworks for the last 12 years and I still struggle with logging in 2012.
I’m not a log expert and I’m sure all these frameworks exist for good reasons (I’m trying to be politically correct here), but for god sake, we just need to write logs. I don’t want to do a benchmark of all the logging APIs to make up my mind. I don’t want to have to relearn a new logging framework each time a new version of my application server is out.
So how do we solve this logging headache? Goncalves argues
that now is the perfect for logging standardisation. “Standardizing
too soon is bad… but we’ve been doing logs for more than a decade
now,” he says. Many were banking on
modularity to solve the problem, but with that ship not docking
until Java 9, it just isn’t an option anymore. But when modularity
is enforced, having a standardised Logging API at Java’s disposal
should make portability far easier.
Goncalves realises that he isn’t the man to be spec lead for this, with his expertise lying elsewhere, but is calling upon others within the logging community to take the baton on this.
Are you the person to lead? More importantly, do you agree with him that logging is something which Java needs to tackle now before it’s too late? Give us your opinion below.
Image courtesy of decade_null on Flickr