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
situation
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
FileUtils.
Thanks everyone for feedback
Kev
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
