ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kev Jackson <>
Subject Re: [patch] NioFileUtils, Java6FileUtils, FileUtilsAdapter + factory, build.xml (was Re: AW: Adding a methof to StringUtils)
Date Fri, 21 Apr 2006 07:13:37 GMT
Martijn Kruithof wrote:

> Hi,
> Adding setting the property using -D to ANT_OPTS should do.
> 5 things:
> 1) I saw you removed public members (constants) from FileUtils (Non 
> backward compatible change, keeping everything BC also frustrates me 
> sometimes, but still I think it is best not to break parts we do not 
> know of.)
Yes that was a mistake, I thought that they'd be available from the 
interface, but realised after I sent the email that only Copy is using 
the interface and all other tasks are still tied to the implementation.  
I need to put this back in the default impl to retain bwc as you mentioned.

> 2) If the FileUtilsFactory is called from or implemented in 
> FileUtils.getFileUtils() / FileUtils.newFileUtils(), every task is 
> going to benefit.
I think the implementation I provided does precisely this, or rather it 
calls from the interface (FileUtilsAdapter) instead of from the 
implementation.  If you mean that the current FileUtils should delegate 
to another implementation using the factory that's different.

I think it would be cleaner to gradually transition all the tasks over 
to an interface (while retaining the FileUtils semi-singleton).  At the 
point where all the tasks are using FileUtilsAdapter, we can refactor 
and remove the parts of FileUtils that are exposed correctly in the 
interface, maintaining bwc that way - the only thing left would be a 
small stub which contains the static methods - that's my view of how a 
transition would work anyway.

I think that using FileUtils to delegate/proxy to a real class would be 
less 'elegant' than using an interface - although I can see the 
immediate advantages of using the approach you mentioned (all tasks 
benefit without actually having to change each class over to the interface).

> 3) Again / Still the actual copying has been moved to the 
> ResourceUtils, how do we make sure that files addressed as resources 
> also benefit from this change.
I'm not sure what you mean by this - the code is proof of concept to 
show that it would be possible to add in nio based file handling in a 
way that minimizes problems of bwc.  I didn't attempt to add nio for 
handling resources - indeed that would mean changing the ResourceUtils 
class, which I didn't want to do as it would have been a big waste of 
time if the overall strategy was wrong.  Right now I just want to play 
with some basic ideas and see if people here on dev list thing that the 
strategy is good/hopelessly broken/not worth pursuing

The intention isn't to be a complete solution to all resource handling, 
just to be complete enough to provide a background for further 
discussion - I fully expect most of the code to be thrown away, but 
without something that executes it's hard to see the potential flaws.

> Regarding the changes in the Copy task:
> 4) Stringbuffer is not more efficient than concatenation using + in a 
> single statement.
Sorry this was change that I didn't roll-back from earlier, it shouldn't 
be there

> 5) StringBuffer handling is incorrect for the second part, (you will 
> concatenate all to filenames.)

again please dis-regard this part of the code as it isn't meant to be there

This shows what happens when you have several different ideas being 
worked on at the same time and you create a unified diff without 
looking! (my bad)

Thanks for the comments

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

View raw message