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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
