ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kev Jackson <>
Subject Re: AW: Adding a methof to StringUtils
Date Thu, 20 Apr 2006 02:04:16 GMT
Dominique Devienne wrote:

>>The point about building the strings when they aren't used (because
>>logging verbosity is set too low) still stands though - this is less
>>than efficient
>The point, which Matt already raised, is that you can't know the level
>at which the logger and the listeners are set. There is nothing ATM in
>the Ant codebase to tip off the project as to the min log level of all
>logger+listener to implement your optimization. This could be can be
>added though, and would be useful IMHO, but that's a separate thread.
I know, that was why I didn't want to wrap the log code in if(verbosity 
 >= Project.MSG_INFO) conditionals - it's sort of a catch-22 situation, 
you don't want to log the message (or even bother building it) if it 
won't be used, but that can't be determined, so you must build the 
message just in case - I agree a mechanism for you to retrieve the 
minimum logging level of the entire project would be useful in this 

>The StringBuffer optimization is well known. I've either read about it
>in Effective Java or the "K&R" of Java, The.Java.Prog.Lang.
I think it was in Effective Java, but as Alexey showed previously, 
Java1.4+ actually perform this operation for you, letting you be as lazy 
as you like with String concatenation (now that's progress!).  I have to 
stop beating up the junior devs here whenever I see sqlString = "Select 
" + field + " from " + table + " where " + field + " = value"; as we are 
on 1.4 internally so it doesn't degrade performance anymore.  Still I'd 
prefer to be able to do something like "yada yada ${var1} yada yada 
${var2}" like the property expansion that is already in Ant - I 
personally think it's much cleaner than "yada yada " + var1 + "yada 
yada" + var2., even the Java5 printf isn't as nice as it could be for 
constructing messages (although it's a long way forward).

>I think what you propose to do would clutter the code, and make it
>ugly frankly ;-) I'd probably -1 it unless you can show hard evidence
>of it's usefulness.
If it came to it I'd -1 it too!  I don't like any of the solutions I 
could come up with yesterday, the one I showed was the 'least worst' 
that I could think of, with a semi-upgrade path to Java5 style varargs 
(use an object array).  I was mainly throwing the idea out to see what 
peoples reactions were - overall I don't think it's the right way to 
solve the problem - the real problem is that the level of logging cannot 
currently be determined and so any optimization (for memory or 
performance) is actually changing the behaviour of the code - which it 
shouldn't do.

The delete task was just an example - I was looking at it to fix 'delete 
task won't be quiet' bug in bugzilla, and I was also thinking about the 
problem with AppFuse, (which does use Delete a little, but not as much 
as Copy and other tasks), so it seemed like a handy guinea pig as I had 
the code open at the time.

I was also looking at Copy and saw that ResourceUtils.copyResource is a 
static method, but FileUtils.copyFile is not even though it delegates to 
copyResource, this means that in Copy there must be an instantiated 
fileUtils object, just to perform the copy, unfortunately the FileUtils 
interface/API is public so changing it would break bwc, but I'd like to 
add a static method for copyFile so that Copy wont need to instantiate 

Thanks everyone for feedback

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message