The JDK 1.4 logging API is being developed part of JSR47, led by Graham Hamilton. Log4j (which is logging API used by TheServerSide.com) began as an alphaWorks project by Ceki Gülcü, and is now part of the Apache Jakarta group. Ceki Gülcü performs a comparison and urges us to lobby Sun to adopt log4j as the logging API shipped with JDK 1.4.

Read JSR47 vs. log4j.

What do you think?

I perfectly agree with Ceki on this one!!! I think it will be very very very very difficult to use multiple logging APIs in a component based environment like J2EE. Let Sun at least implement something like a pluggable logging engine.

But well, that might even not be possible if Sun's implementation differs on such big issues as the priorities and the inheritance of categories.

I'm not saying either of them is better than the other (though I tend to say Log4J is more mature) because I haven't really investigated JSR47, but let people at least work together somehow.

Alef Arendsen
Software Engineer
SmartHaven - Every Bit Personal

Alef,

 By all means, voice your opinion by emailing the JSR 47 group!

Floyd

    The Arguments is definitely one sided.
See the Following line:
    "Log4j has an extensible and powerful layout called the PatternLayout. JSR47 offers the much weaker SimpleFormatter as an alternative."
This is not completely true as the structure in logging API is as follows:
        Formatter class which can be extended to provide flexible formatting. Sun provides 2 formatters 1) Simple Formatter 2) XML Formatter.
        Since these classes are not final what is stopping develoeprs from writing their own Formatters?
 
Event the point author mentioned about performance proved false when i tried my test cases. Definitely jdk1.4 logging is 3 times faster than log4j when message should not be logged(The case I tested).

Kumar.

Kumar,

No one is stopping developers from writing new handlers and
layouts. However, the logging functionality provided as "standard"
with JDK 1.4 should meet common needs. In my opinion, that is not the
case. What's the advantage of including a logging API in the JDK if
you need extra software to actually use it properly?

As for performance, please see the updated section entitled
Performance in http://jakarta.apache.org/log4j/docs/critique.html.

Again, don't trust my opinion, test JSR47 for yourself and make up
your own mind. Regards, Ceki

Ceki,

  Why do you assume what Appears in JDK1.4 is going to be final? As part of JDK1.5 new classes may be added providing additional "common needs" you are talking about.

  Also did you try checking the performance of Log4J with Jdk1.4 when logging is turned off? My results showed to me that in this perticular case JSR is better than Log4J.

BTW As I mentioned Earlier, I do use Log4J in all my projects and definitely like. All I was saying is Logging cannot be dropped from jdk1.4 or this is not the point where complete redesign can be discussed.

Kumar.

 

Kumar,

> Why do you assume what Appears in JDK1.4 is going to be
> final? As part of JDK1.5 new classes may be added
> providing additional "common needs" you are talking about.
  
JDK 1.5 will not be out before 2004-2005.

> Also did you try checking the performance of Log4J with
> Jdk1.4 when logging is turned off? My results showed to
> me that in this perticular case JSR is better than Log4J.

Yes, this is mentioned in the updated version of my critique.

> BTW As I mentioned Earlier, I do use Log4J in all my
> projects and definitely like. All I was saying is
> Logging cannot be dropped from jdk1.4 or this is not
> the point where complete redesign can be
> discussed.

Nice to hear. Have you tried using the JSR47 logging API yourself? Adopting log4j would not be a redesign but a better implementation of the same. Regards, Ceki

 Good thinks won't happen over night :-)

>Yes, this is mentioned in the updated version of my critique.
Great. Thanks that you numbers exaclty match as I mentioned in my first posting int his thread.
In production Environment most of the Time anyone would prefer to turn of logging. JSR47 has three times better performance than Log4J in most commonly used case. I don't care even if Application is slow when I am debugging.

>Have you tried using the JSR47 logging API yourself?
Yes. I don't see any major problems in using JSR47. BTW the only problem for me was that JSR47 works only for jdk1.4. I feel this is a problem for timebeing as I am not going to use jdk1.3 few months after jdk1.4 release is Final as I don't use jdk1.1 or jdk1.2 any more.

Kumar.

You don't say what you tested. I very much doubt that JSR47 outperforms log4j.

6 months after the release of JDK 1.4, I performed a google search on log4j, with 120'000 results. The same search for "Java 1.4 logging" results in 48'600 results. We'll see in another 6 months.

looking at these levels, atleast I don't think someone is interested in doing a really good job rather it is an attempt to fill in the void that's been there since jdk went live with something different than good stuff already out there.

SEVERE (highest value)
WARNING
INFO
CONFIG
FINE
FINER
FINEST (lowest value)

I agree with the author of the critique.

I also would recomend looking at Protomatter Syslog (http://protomatter.sourceforge.net). It was featured in a recent JavaWorld article, and is in use in many commercial production environments.

-nate (Syslog author)

Nate,

 How come you didn't send the same message to SUN when you JSR47 started?
 Who stopped Ceki from participating in JSR as an individual participant?

 Why are these issues not raised Before Merlin beta came out?
 Graham's response sounded very reasonable.

 BTW As a matter of fact I use Log4J in my projects but that doesn't mean I don't expect anything better than Log4J.

 
Kumar.

Many of Ceki's complaints stem from the limited functionality available out-of-the-box in JSR47, but that is the way it _should_ be. It is nice to have lots of formatting options built in to Log4J, but I don't want 7 different kinds of layout formatters etched in the stone of a Java API. It is great to be able to log directly to the NT event subsystem, but I don't think that functionality belongs in every single web-browser plugin running Java. Every single project I work on uses Log4J, but I think that Ceki is being too harsh on JSR47.

Keep the interface simple and let third-party implementations add functionality.

 - Nathan

Nathan,

1)Those log4j appenders and layouts which are judged unnecessary can
be left out.

2) Don't trust my opinion. Just try out the logging API in JDK 1.4 for
yourself. Regards, Ceki

There are a number of other logging implementations around
as well, none of them are happy with JSR047 for example
a great critique can be found here:

http://www.swzoo.org/documents/miscellaneous/jsr047

Michael,

 A year(1-2 yrs actually) back similar comments appeared on JSP Spec.
 Finally JSP Spec won. I believe this is because every one likes their own kid.

Kumar.

Kumar,

It is *not* a case of everyone "liking their own kid"
as you put it.

Back in November 2000 when the JSR-000047 was opened
for public review I submitted (on behalf of the Software
Zoo):

    http://www.swzoo.org/documents/miscellaneous/jsr047/

It was a "critique" of the JSR-000047; not a plug for
LV2 (the Software Zoo's logging). The "critique"
outlined 4 major areas the JSR-000047 proposal fell
short on. The "critique" was *backed up* by our logging
implementation.

The 4 major areas are:

    1. Provide a "pluggable" logging architecture.
    2. Define and enforce a much clearer separation
       between a user of logging and the configuration
       of logging.
    3. Provide for distributed logging.
    4. Remove superfluous parameters and methods from
       the API.

At the time we relied on the "good will" of the JCP process
and expected the recommendations in the "critique" to be
taken onboard. None of them have been; in any form.

Every person I have corresponded with in regard to
java.util.logging, whose technical ability I respect, see
the API as inadequate. The fact that java.util.logging
makes it *extremely* difficult to "plug in" any other
logging packages is its greatest failing.

Based on what is currently available in the java logging
arena, java.util.logging is a very substandard API.

Surely, based on this feedback, and the availability of
superior APIs, the warning signals should be going off
within the JSR-000047 expert group and Sun. Including the
fact that at least one person *in* the expert group believes
java.util.logging should be removed.

Unless significant work is done, java.util.logging should
be PULLED from JDK1.4 before FCS - better no API, than a
broken one.

Kumar,

Do you think I enjoy going through log4j bug reports, maintain the software, read a hundred users asking for help? Well, I don't.

I'd be more than happy to delegate those tasks to Sun. The JSR47 API is very close to log4j in many ways. Probably more than any other API. The problem is in the details. Ceki

This has a deja-vu flavor for me and perhaps also for those who are javaold enough (that have used jdk1.1).

Once upon a time, ther was no java.util Collection API
but a great company called Objectspace developed a great containers-algorithms collection for Java (inspired by STL) called JGL. It was widely used, free and came with sources.

But someone up there decided to reinvent the wheel ...

Edo

Will J2SE 1.5 contain any significant enhancements
for java.util.logging ?