Re: Whose log is this anyway? (was Re: [s1] Commons-Lang)

[Don Brown]

This isn't an either/or decision.  As I said before, there certainly are 
cases where the guard is necessary and your example highlights one of 
them.  However, in most cases, it isn't and these cases could use a more 
compact var-args logging call.

Don
Martin Cooper wrote:
On 8/22/06, Tim Fennell <[EMAIL PROTECTED]> wrote:

To add a little weight to Don's comments, the cost of allocating an
array really is *very* minor.  To quote Brian Goetz[1], the cost of
allocating a new object in 1.4.2 and above is approximately 10
instructions (maybe more for an array, but remember that var-arg
calls are optimized at compile time).  And more to the point, since
it's lifetime is very short, the GC overhead is most often zero.  So
the overhead is minor at best.


In that particular case, yes. However, consider the following:

if (isDebugLoggingEnabled()) {
   log.debug("And the answer is: " + expensiveMethodCallHere());
}

I don't know about you, but I'm very thankful for that guard when debug
logging is disabled (e.g. in production). Without it, I'm going to 
make that
expensive method call even if logging is disabled - and then just 
throw away
the result after doing nothing in log.debug. Even a lowly toString() 
call,
frequently used in debug logging, can get expensive, so it's not like 
this
is a corner case.

-1 on getting rid of guards.

--
Martin Cooper


-t

[1] http://www-128.ibm.com/developerworks/java/library/j-
jtp09275.html#resources


On Aug 22, 2006, at 4:21 PM, Don Brown wrote:

> There will always be cases where the isDebugEnabled method will be
> necessary, but for the vast majority of cases, I think the varargs
> solution is perfect.  The very minor cost of an Object array, IMO,
> is well worth the value of code clarity, simplicity, and
> maintainability.
>
> Don
>
> Laurie Harper wrote:
>> The var-args log message construction is definitely a nice bit of
>> syntactic sugar, but removing the guard seems unwise; sure,
>> there's no string concatenation in the call to log.debug, but
>> there's an implicit Object[] instantiation, which isn't much
>> better. There's a reason every major logging API includes
>> isLoggable/isDebugEnabled/whatever guard methods...
>>
>> L.
>>
>> Don Brown wrote:
>>> I think a couple extra classes is worth switching from this:
>>>
>>> public Order createOrder(User user, Product product, int quantity) {
>>>    if ( log.isLoggable(Level.FINE) ) {
>>>        log.fine("Creating new order for user: " + user.username()
>>> +            " product: " + product.name()            + "
>>> quantity: " + quantity);
>>>    }
>>>    return new Order(user, product, quantity);
>>> }
>>>
>>> to this:
>>>
>>> public Order createOrder(User user, Product product, int quantity) {
>>>    log.debug("Creating new order for user: #0 product: #1
>>> quantity: #2", user.username(), product.name(), quantity);
>>>    return new Order(user, product, quantity);
>>> }
>>>
>>>
>>> Considering how often we log things, I think the cleanup is huge
>>> and a few classes are definitely worth the price.
>>>
>>> Don
>>>
>>> Bob Lee wrote:
>>>> On 8/22/06, Don Brown <[EMAIL PROTECTED]> wrote:
>>>>>
>>>>> Well, for one, we only really need one logging instance for the
>>>>> whole
>>>>> library.  Second, and admittedly this is subjective, the
>>>>> java.util.logging API is a horribly designed, obtuse API.  I'd
>>>>> rather
>>>>> see us write a small, clean API along the lines of Seam's
>>>>> logging class
>>>>> that utilizes varargs to reduce the need for isDebugEnabled().
>>>>
>>>>
>>>> I agree that j.u.logging is a PoS, but it's ubiquitous, and for our
>>>> purposes, it workds fine. We may only need one logger for the whole
>>>> framework, but it's just as easy to create a logger per class,
>>>> and you can
>>>> still configure them all at once. I'd rather fix j.u.logging
>>>> than build yet
>>>> another API.
>>>>
>>>> Bob
>>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]