I agree that we should keep an eye on logging. What you propose is
certainly an option. Some random thoughts:
- I wonder how it would affect the source code (readbility). You'd have
to write a debug() method in each class that logs to a separate logger.
- Right now I don't know of any bigger component/project that does this.
Most just rely on the configurability of the logging backend. If you use
log.is*Enabled() you lose only very little compared to the conditional
compilation.
- The ability to turn on more debugging information during run-time (on
a live server) has helped me a number of times before.
- There are probably many log statements in our code that could be
removed. I've started to change debug statements to trace statements.
These are the most likely one that we can remove without giving away the
ability to provide helpful information for those who can use them.
- The parts that will move to Commons should eventually get freed of the
dependency on Commons Logging as agreed.

To your questions:
1) As indicated above I don't think the penalty of the current approach
is big if is*Enabled() is used where Strings are concatenated. And I
don't think the logging statements add too much to the class sizes.
Better make FOP more modular for people wanting to scale down: SVG/Batik as
optional extension, Renderer pluggability as I implemented it and will
commit later today. For the latter we could change the build to make
certain renderers optional or exclude them from the build process
(configurable).
2a) pretty much shows why this approach may not be flexible enough. I
like having the ability to enable the debug level just for certain element
lists (that's why each category is logged to a separate logger) and the
layout managers leaving everything else to "INFO".
2b) Really just see to it that we clean out unhelpful logging statements
and that is*Enabled() is used where necessary.


On 08.11.2005 23:44:24 Andreas L Delmelle wrote:
> Hi all,
> 
> For starters: it's not really a pressing matter ATM, but it may  
> become of relevance if we want to strive for a production-release.  
> The matter is somewhat related to the distinction between developer-  
> and user-directed logging.
> 
> It concerns the numerous log.debug() and log.trace() messages  
> scattered around. Just recently, I was reminded of a little Java  
> trick that emulates C's conditional compilation, which inspired me to  
> pop this question here.
> 
> As you are most likely well aware, every log.debug() generates  
> bytecode at compile-time, which leads to compiled classes being  
> unnecessarily large for general usage. In Java, there exists this  
> little trick to define a final debug() method:
> 
> final void debug(String msg) {
>    if (DEBUG) {
>      log.debug(msg);
>    }
> }
> 
> The DEBUG boolean constant being defined in a central, easily  
> accessible place.
> 
> If subsequently, all log.debug() calls are replaced by mere debug(),  
> and one sets DEBUG to false, then the result at compile-time is that:
> - there is no bytecode generated for the debug() methods (empty body)
> - since the method is final, and it has an empty body, the compiler  
> can optimize further and no bytecode will be generated for any call  
> to it. Meaning also: possible string literals in the message do not  
> take up space in the internalized string-table, which in turn would  
> be beneficial for eventual runtime-calls to String.intern() (smaller  
> table => decreased lookup-time)
> 
> In order to switch on dev-directed debugging code, one would only  
> need to change the value of the DEBUG constant and rebuild from the  
> very same codebase, so the related code gets compiled in.
> 
> Questions:
> 1)  Is there IYO still a benefit to such an approach? After all, if I  
> remember correctly, this trick is quite old, so may bear only little  
> relevance to current JVM's? The class-size argument may still make it  
> worthwhile, nonetheless. (FOP is already a reasonably large package  
> in itself, leaving out all the debug-related code...)
> 
> If yes/pro:
> 2a) How should we go about that?
>    * Location of the centralized DEBUG constant?
>      (hardcode it? make it settable as a build property?)
>    * One debug()/trace() per class having a log instance member?
>      (could lead to conflicts: inability to override final method?)
> 
> If no/contra:
> 2b) Any alternatives?
> 
> 
> Cheers,
> 
> Andreas



Jeremias Maerki

Reply via email to