JSR47 vs. log4j as a standard logging API for JDK 1.4

Discussions

News: JSR47 vs. log4j as a standard logging API for JDK 1.4

  1. 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?

    Threaded Messages (19)

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

  3. Alef,

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

    Floyd

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


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

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

     
  7. 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
  8. JDK 1.5 will not be out before 2004-2005.

     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.

  9. 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.
  10. 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)

  11. 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)
  12. 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.
  13. 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


  14. 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
  15. 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
  16. 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.
  17. 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.

  18. 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
  19. 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
  20. java.util.logging and J2SE 1.5[ Go to top ]

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