We want you - as spec lead

Forget cloud standardisation – we need a Logging API in Java

Chris Mayer
logging

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
line.

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.

Goncalves adds:

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

Author
Comments
comments powered by Disqus