Maurizio,

Every now and then there is a question about log4j vs. the JSR47 "standard". 

As the founder of the log4j project my opinion is heavily biased. You have been warned.

It is upsetting to hear people talk about the JSR47 "standard" when no one outside Sun 
has ever seen the thing running, at least not yet. JSR47 has been very heavily 
influenced by JLog, IBM's Logging Toolkit for Java. Log4j also draws from JLog 
although not nearly as heavily. By the way, log4j also originated at IBM, it was also 
distributed at alphaworks for some time, but the code bases are *totally* different. 
Some people still refer to log4j as IBM's logging package, which is rather 
unfortunate. 

JSR47 is not nearly as complete as JLog or log4j. It is basically a skeleton API which 
is fine in itself. However, in my not so humble opinion, compared to log4j it has 
several important drawbacks. See http://www.qos.ch/ac2001/F11-200.html for a list. It 
must also be said that none of the drawbacks are fatal. The people at Sun are not 
exactly stupid. They will eventually correct their mistakes. When they do, the JSR47 
API will look a lot like log4j. It already does substantially.

The log4j package, in one form or another, has been around for over 5 years. It has 
over 30'000 lines of code. I expect JSR47 to be around 3'000 lines when released. Two 
years ago, log4j had that size with roughly equivalent functionality.

JSR47 can be extended. One can define new output targets and formats. However, as far 
as I know, JSR47 core is not designed to be extended. In contrast, log4j core can be 
extended. For example, using log4j you can define your own category subclasses and new 
priority levels. 

This extensibility allows log4j to be adapted to users needs. It is not hard to wrap 
log4j so that is looks like JSR47. This is has been actually done although there a few 
caveats. In particular, the user cannot add code which is under the java.xxx 
"standard" package hierarchy.   

In a nutshell, it is not at all clear which logging package will be most widely used 
in say 3 years. Log4j has been ported to C++ and Python. That will become an 
overwhelming advantage in due time. Log4j has many unique features and more are being 
added every day. As such, I would not bet on the long term success of JSR47. It's only 
advantage is to be shipped with the JDK. It's certainly a huge advantage but not 
necessarily a decisive one. 

We started a few years ahead. I hope this answers your question. Ceki 

ps: Community and standard compliant are just words. It is important to see what 
actually lies behind these cozy words. 

At 12:53 18.04.2001 +0200, Maurizio Taverna wrote:
>I'm interested to know what do you think about the JSR000047 and if the
>Log4j will be compliant with the specification in the future. In the Ceki
>'s Java World Article
>(November 2000) I read : "Log4j already provides support for bridging int
>the JSR47 API".  Most of my customer are interested in open source but 
>they give a look if the implementation are standard API compliant. I belive
>It could be possible to introduce a facade API compliant component and I'm
>interested to know
>if an implementation is already available. In any case I would like to work
>with it if , of course, its interesting for the community.
>
>Thank you 
>
>Maurizio
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]

--
Ceki Gülcü


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to