Having separated out the FileFilter implementations I then went off and had a look at what Commons IO provided. Their IOFileFilter interface is a combination of the java.io.FileFilter and java.io.FilenameFilter interfaces and they have a number of implementations that we could use in place of those in Finder. Plus I've submitted 4 new ones to Commons IO:
http://issues.apache.org/jira/browse/IO-85 Also on the horizon is a Regex implementation whenever IO moves to JDK 1.4: http://issues.apache.org/jira/browse/IO-74 Potentially then we could get rid of most of our implementations and use the IO ones: CompositeFilter --> AndFileFilter / OrFileFilter (now) CanReadFilter ---> CanReadFileFilter (IO-85 submitted to IO) CanWriteFilter ---> CanWriteFileFilter (IO-85 submitted to IO) EmptyFilter ---> EmptyFileFilter (IO-85 submitted to IO) HiddenFilter ---> HiddenFileFilter (IO-85 submitted to IO) MinFilter ---> AgeFileFilter (now) TimeFilter --> AgeFileFilter (now) NewerFilter --> AgeFileFilter (now) NameFilter ---> WildcardFileFilter (IO 1.3) RegexFilter --> RegexFileFilter (IO-74 submitted to IO) TypeFilter ---> DirectoryFileFilter (plus NotFileFilter) (now) There is a SizeFileFilter in IO, but it doesn't work exactly the same way as SizeFilter. The only other imlementation is PathFilter which doesn't have an equivalent in Commons IO. Anyway the upshot of it is I think we should switch finder from using java.util.FileFilter to IOFileFilter and plug in the implementations that are currently available in IO 1.2. Any objections? Niall --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]