Re: Possible API Performance and Usability Enhancement

[Curt Arnold <ca...@apache.org>]

On Aug 29, 2005, at 2:52 PM, Dan Bush wrote:

> Excellent.
>
> On 8/29/05, Ceki Gülcü <ce...@qos.ch> wrote:
>
>>
>> Dan.
>>
>> Are you aware of SLF4J API which already incorporates a similar  
>> approach?
>>

The same pattern is also in the CVS HEAD.  However, I think there is  
a better approach.  This topic was discussed on the slf4j-dev mailing  
list earlier in the thread "NLS in Logger" starting in 2005-08-05  
(http://marc.theaimsgroup.com/?l=slf4j-dev&m=112327572703543&w=2).

The current approach in the CVS HEAD, slf4j and nlog4j implement a  
subset of the behavior of java.text.MessageFormat.   I have not had  
time to confirm whether the subset implementation actually offers any  
performance advantage over java.text.MessageFormat.  However,  
java.text.MessageFormat is just one of the potential formatters, like  
the JDK 1.5's java.util.Formatter, that could be used.

In addition, if you review the slf4j-dev mailing list, you will see a  
some discussion about what combinations of parameters should be  
supported in the overloaded logging methods.  For example, http:// 
marc.theaimsgroup.com/?l=slf4j-dev&m=112313497512402&w=2.  The  
decision of what parameters are supported is a compromise between  
performance and complexity and what is a good balance for one  
developer may be less than optimal for another.

My current suspicion is that an approach of using an static class  
would result in performance close if not identical to the approach in  
CVS HEAD on a modern JIT, would not lock developers to one formatter  
and would allow the developer to use an alternative implementation if  
desired.

The approach is basically something like:

public final class LogFormat {
     private LogFormat() {}


    public static debug(final Logger logger, final String format,  
final Object param1) {
         if (logger.isDebugEnabled()) {
             logger.debug(java.text.MessageFormat.format(format.  
param1));
        }
    }

    //
    //    many more combinations of parameters to follow
    //
}

In use, it would look something like:

LogFormat.debug(logger, "ci:[{0}]", ci);

I'd assume that modern JITs would effectively inline the LogFormat code.


---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org