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.
-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]
