What about JSR000047

[Maurizio Taverna <m....@tin.it>]

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: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org

Re: What about JSR000047

[Ceki Gülcü <cg...@qos.ch>]

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: log4j-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: log4j-dev-help@jakarta.apache.org

--
Ceki Gülcü


---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org

Re: What about JSR000047

[Ceki Gülcü <cg...@qos.ch>]

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: log4j-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: log4j-dev-help@jakarta.apache.org

--
Ceki Gülcü


---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org