DO NOT REPLY [Bug 30094] - Performance enhancements using java.nio & lazy calls

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=30094>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=30094





------- Additional Comments From kevin.jackson@it.fts-vn.com  2006-04-20 07:54 -------
(In reply to comment #13)
> It could be a compile-time-optional part of the runtime, something that is only
> delegated to when the runtime is 1.4+. Which means that we'd need an
> interface/facade to the operations and then an original+nio implementation, 

(pushed here from Antoine on the dev list ...)

I've started looking into this and I can see that we need an interface of the
current FileUtils class (minus static methods) and then a factory to select the
implementation, and 2+ implementations, original/classic (ie what we have right
now), NioFileUtils (such as this code here in this bug report) and
Java6FileUtils (for all the file permission goodies).

I'm not sure how to resolve the problem that *a lot* of the current code
presumes a lot about FileUtils (ie that certain methods are static etc).  Since
we have to maintain bwc, this will probably have to mean that the interface
contains definitions of all instance methods, and the original FileUtils will
have to keep the static methods (as they are public) and any new implementation
will have to delegate to the original for these methods.

Is this a sensible strategy?
Kev

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org