JSR47 vs. log4j

Is JSR47 reinventing the wheel?

by Ceki Gülcü

As of version 0.8 of the JSR47 specification the java.util.logging API resembles log4j even more than was the case previously. The way the two APIs name their components may differ but otherwise their degree of resemblance is quite striking.

Changes introduced in the latest 0.8 draft include configuration order independence, appender inheritance, resource bundle inheritance, error handlers and lazy inference of caller information. In other words, even if the priority levels remain unchanged and somewhat bogus, the majority of the points raised in my critique of JSR47 are now obsolete.

Consequently, it is fair to say that our campaign to influence the JSR47 API handsomely bore fruit. I wish to thank the hundreds of concerned users who have expressed their support for log4j. My gratitude goes to Jason Hunter for arranging the appropriate communication channel to Sun. Graham Hamilton, the JSR47 specification lead, was very open and receptive during our exchanges.

From the user standpoint, there remain two critical differences. First, JSR47 requires JDK 1.4 whereas log4j is compatible with JDK 1.1 and later. Second, log4j offers much more functionality. It supports a rich configuration language, at least a dozen appenders and layouts as well as many other useful features.

Efforts to backport JSR47 to earlier JDKs are doomed to fail because the java.util.logging package is located under the java namespace. This will cause backported code to systematically throw a SecurityException under JDK 1.3. Moreover, Java is a trademark owned by Sun Microsystems. As such, the backported code will be under the threat of litigation as long as Sun can be expected to defend its trademark.

If you look at the terms of the final draft of the JSR47 specification, you will discover a copyright notice containing the following text.

  Sun hereby grants you a fully-paid, non-exclusive, non-transferable,
  worldwide, limited license (without the right to sublicense), under
  Sun's intellectual property rights that are essential to practice
  the Specification, to internally practice the Specification solely
  for the purpose of creating a clean room implementation of the
  Specification that: (i) includes a complete implementation of
  the current version of the Specification, without subsetting or
  superset-ting; (ii) implements all of the interfaces and
  functionality of the Specification, as defined by Sun, without
  sub-setting or supersetting; (iii) includes a complete
  implementation of any optional components (as defined by Sun in the
  Specification) which you choose to implement, without subsetting or
  supersetting; (iv) implements all of the interfaces and
  functionality of such optional components, without subsetting or
  supersetting; (v) does not add any additional packages,
  classes or interfaces to the "java.*" or "javax.*" packages or
  subpackages (or other pack-ages defined by Sun); (vi)
  satisfies all testing requirements available from Sun relating to
  the most recently pub-lished version of the Specification six (6)
  months prior to any release of the clean room implementation or
  upgrade thereto; (vii) does not derive from any Sun source
  code or binary code materials; and (viii) does not include
  any Sun source code or binary code materials without an appropriate
  and separate license from Sun. The Specification contains the
  proprietary information of Sun and may only be used in accordance
  with the license terms set forth herein. This license will terminate
  immediately without notice from Sun if you fail to comply with any
  provision of this license. Upon termination or expiration of this
  license, you must cease use of or destroy the Specification.

Given these business terms it is not possible for log4j or other independent parties to implement the JSR47 specification. Here is how the Apache Software foundation, a member of the JCP Executive Committee, voted on this JSR.

The Apache Software Foundation is grateful for the significant efforts of the JSR 47 spec lead, Graham Hamilton, toward addressing the technical concerns raised by the members and lead of Apache's log4j project. Regretfully, under the Merlin business terms, log4j (or any other potential independent implementation of this specification) cannot make use of the Specification, not can anyone implement this specification for earlier J2SE platforms (J2SE 1.2, 1.3), and it is on this basis that Apache cannot support this JSR.

Even without the SecurityException and the licensing issue, you would need an additional logging library to fill in the functionality gap, the JDK compatibility gap, or both. If you are going to install one or more logging APIs, then why not install log4j which offers a lot more than JSR47 and is backward compatible with JDK 1.1?

Log4j is the de facto standard logging API in Java. It has been ported to Python, C, C++, Eiffel and the much maligned C#. By adopting log4j, you simultaneously benefit from much richer functionality and wider JDK compatibility. In any case, with the support of the log4j community, the log4j project will continue to innovate and lead the way. As such, many of the features that you need or will need in the future will be first available in log4j.

Remaining differences

The remaining differences are admittedly of secondary importance. None of them will cause you to think "oh, that is a showstopper." You will probably shrug and move on to the next item.
  1. Filter logic

    As in Linux ipchains, log4j filters use ternary logic. In JSR47, filter logic is binary. Mathematically the two logics are equivalent except that it is much easier to combine generic filters in log4j's ternary logic than in JSR47's binary logic


    For example, if you would like to reject a log message if it contains the string "Microsoft" or the string "proprietary code", accept messages having the info priority and only the info priority and reject everything else, you would write:

      <filter class="org.apache.log4j.varia.StringMatchFilter">
        <param name="StringToMatch" value="Microsoft" />
        <param name="AcceptOnMatch" value="false" />
      <filter class="org.apache.log4j.varia.StringMatchFilter">
        <param name="StringToMatch" value="proprietary code" />
        <param name="AcceptOnMatch" value="false" />
      <filter class="org.apache.log4j.varia.PriorityMatchFilter">
        <param name="PriorityToMatch" value="INFO" />
        <param name="AcceptOnMatch" value="true" />
      <filter class="org.apache.log4j.varia.DenyAllFilter"/>

    You cannot express this policy with JSR47 filters without writing a filter for exactly this policy.

  2. Filters in loggers (categories)

    JSR47 allows filters to be attached to loggers (categories in log4j speak) and also to handlers (appenders in in log4j speak). Log4j allows filters to be attached to appenders but not to categories.

    In short, attaching filters to loggers is a feature that JSR47 offers but log4j does not. However, because arbitrary logic cannot be meaningfully composed, filters cannot be inherited. Thus, you would need to attach a filter to every single logger where you would like it to apply.

  3. Bogus levels

    JSR 47 defines the levels ALL, SEVERE, WARNING, INFO, CONFIG, FINE, FINER, FINEST and OFF.

    Having three debugging levels FINE, FINER, FINEST could seem like a good idea. However, you will soon discover that even when by yourself, it is hard to decide when to use which level. It is plain impossible in groups.

    Arguing about priority levels is a bit like arguing about your favorite color. I will thus stop here.

  4. Plethora of printing methods

    The set of printing methods in the Logger class is confusing. It is all there -- just not where you would expect them to be. For example, you cannot log an exception with the warning or severe methods. You will need to use the log method instead.

  5. Sequence numbers

    JSR47 emits sequence numbers in each log record it creates. The sequence number is synchronized using the LogRecord class itself at the cost of a small but measurable performance penalty. This variable is not likely to be very meaningful if the logging output is split between different handlers as the output of each handler will contain holes in the sequence numbers.

Stop reinventing the wheel

There are many other details in which log4j differs from JSR47. Even if the log4j core is small, the project contains a total of over 30'000 lines of well-tested code. JSR47 contains about 5'000 lines of code.

Log4j has been around for a number of years, enjoys the support of an active community and is being used in thousands of projects. Our site gets over 600 downloads each and every day, and the numbers are on the rise. Companies are also offering commercial products extending log4j.

Here is a short list of open source projects or sites that are known to use log4j.

Sun might be setting a dangerous precedent by ignoring a rather successful open source project. If it happens to log4j, can it happen to your project?

Lobby Sun

If you feel that Sun is reinventing the wheel and setting a dangerous precedent, then this the time to lobby Sun to adopt log4j as the official logging API for the Java language.

Please direct your polite and personalized request to jsr-47-comments@jcp.org with Bcc: to ceki@qos.ch.

Many individuals have written to Sun to express their concern, in their vast majority pushing for the adoption of log4j. Their names and the content of their request are listed below. I am very grateful for their support. Some of these requests are quite detailed and insightful.

Most of the e-mail notes are reproduced with permission. However, do not hesitate to contact ceki@qos.ch in case you are uncomfortable seeing your name or the contents of your request reproduced publicly.