Log4j versus JDK 1.4 Logging

This page describes some of the differences between the log4j API and the logging API included as part of Sun's JDK 1.4.

Why would you use log4j instead of the JDK logging API?

  • Log4j has been around since 1998 and many developers consider it to be a more mature framework.
  • Log4j 1.2.X is compatible with JDK 1.1 or later, Log4j 1.3 will be compatible with JDK 1.2 or later. The JDK 1.4 logging API requires JDK 1.4 or later. Consequently, if your applications needs to be deployed in a heterogeneous Java runtime environment, log4j can be considered as a safer bet.
  • Log4j has a much richer feature set. It has many more extensions that can be immediately used "out-of-the-box". Log4j includes many appenders (sinks or destinations for logging information) that JDK logging does not support out-of-the-box, e.g. SMTP, JDBC, and JMS.
  • As an open-source project, log4j continues to be developed and improved at a rapid pace. The improvements planned for log4j 1.3 will bring unparalleled functionality. The advancement of the technology in the logging related space is going to move faster in the log4j space than it is in the Sun/JDK space. Through bug fixes or talented committers joining the effort, more can happen here at Apache than can effectively be done at Sun where the focus and effort is on other things (like staying in business and not being crushed by M$, HP, IBM, etc).
  • Log4j includes log analysis GUIs: Chainsaw and 
     LogFactor5
    .
  • Log4j commands a tremendous mind-share. Developers continue to make components available for the log4j framework, and in some instances only for the log4j framework.
  • Log4j performs well under heavy load. The next version of log4j should perform even better under extremely heavy load.
  • Being involved in an open source community means you can fix bugs, get your own patches applied in a timely fashion and have an influence over the future direction of the project.
  • In summary, if you are serious about logging, then log4j unfolds as the best option, probably by a large margin which keeps on widening.

Here are a list of other comparisons:

and an out-dated critique (read the Web Archive article for an update)

  • No labels