Delivered-To: cgu@qos.ch
X-Sender: scottalodar@24.1.141.11
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 18 Jun 2001 19:35:42 -0700
To: java-logging-input@eng.sun.com
From: Scott Ellsworth <scott@alodar.com>
Subject: Please reconsider adopting order independence for jsr-47, a la
  log4j
Cc: cgu@qos.ch

Hello.

I am quite excited that Java will be getting a logging facility in the near future.  Such facilities have saved us countless hours of debug time.

Our development team started using log4j roughly six months ago, and we have become quite enamored with it.

At http://jakarta.apache.org/log4j/docs/critique.html, you will find a detailed summary of what one of the authors felt should change about jsr-47.  I found his arguments compelling, but of those arguments, three are paramount.

1.  The ability to declare my hierarchies in any order.

Very often, I will want to turn logging on at a verbose level in org.metagraph.persistence.jdbc, off at org.metagraph.persistence, and on at info for org.metagraph.  With log4j, I can do this in any order, as when I set a given level, it can walk up the tree.

This is a wonderful feature, as it means that I can edit my config files without a lot of extra effort to make sure the order is right.

2.  The logging in log4j is faster if the statements are not evaluated.

According to the analysis at the above web site, we will suffer a far larger penalty when not logging than we have to.  As best my own perusal can tell, this is true.  While this makes the penalty when logging a bit smaller, this is less important for my applications.  Consider, a log message is likely to go to disk or network, thus there will already be substantial overhead.  Adding the small amount for a runtime check is a minor matter.

Adding overhead when not logging is very, very bad.  It means that more of our code will have logging removed at the source level.

3.  Make very, very sure that under NO circumstances will a runtime error or exception get propagated to the user.  If my program behaves differently depending on what log level is active, I have just had my testing tasks increased immeasurably.  The effect will be the removal of log statements by developers, and it is hard enough to get them to use them.

On a separate note, we will not be able to move full time to jdk 1.4 for quite some time.  By putting the logging kit in java.util, we cannot install a 1.3 version.

Were you to put it in javax, I could write 1.2 or 1.3 code that works happily without security exceptions.  Please consider this move.

Scott
Scott Ellsworth
scott@alodar.com