You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Niall Pemberton <ni...@gmail.com> on 2006/07/21 21:22:59 UTC
[finder] Switch from java.util.FileFilter to Commons IO's IOFileFilter
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [finder] Switch from java.util.FileFilter to Commons IO's IOFileFilter
Posted by Henri Yandell <fl...@gmail.com>.
Makes a lot of sense to me - +1.
On 7/21/06, Niall Pemberton <ni...@gmail.com> wrote:
> 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [finder] Switch from java.util.FileFilter to Commons IO's IOFileFilter
Posted by Niall Pemberton <ni...@gmail.com>.
On 7/22/06, Henri Yandell <fl...@gmail.com> wrote:
> On 7/22/06, Stephen Colebourne <sc...@btopenworld.com> wrote:
> > Niall Pemberton wrote:
> > > 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?
> >
> > I guess my POV is known on inter-commons dependencies - they are best
> > avoided for a whole heap of reasons. However we don't seem to be able to
> > agree on a consensus opinion on this subject.
>
> My thinking is to encourage dependencies until a release gets close -
> then to question them. In this case it's going to be good as much of
> the code in Finder will either vanish completely or be donated to IO.
> That'll leave a much smaller API and I suspect then it might be
> something that looks desirable for IO again. If not though - it'll
> still be ready for release as its own component.
+1 I know your original goal was to emulate the Unix find command, but
for me I'm less wedded to unix's implementation and more to the
concept of navigating. I read this wrt to unix find:
"if you use the whatis command to see what it does the answer may
surprise you - 'walk a file hierarchy'".
IMO an implementation of that concept would IMO be a good addition to IO.
Niall
> Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [finder] Switch from java.util.FileFilter to Commons IO's IOFileFilter
Posted by Henri Yandell <fl...@gmail.com>.
On 7/22/06, Stephen Colebourne <sc...@btopenworld.com> wrote:
> Niall Pemberton wrote:
> > 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?
>
> I guess my POV is known on inter-commons dependencies - they are best
> avoided for a whole heap of reasons. However we don't seem to be able to
> agree on a consensus opinion on this subject.
My thinking is to encourage dependencies until a release gets close -
then to question them. In this case it's going to be good as much of
the code in Finder will either vanish completely or be donated to IO.
That'll leave a much smaller API and I suspect then it might be
something that looks desirable for IO again. If not though - it'll
still be ready for release as its own component.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [finder] Switch from java.util.FileFilter to Commons IO's IOFileFilter
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Niall Pemberton wrote:
> 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?
I guess my POV is known on inter-commons dependencies - they are best
avoided for a whole heap of reasons. However we don't seem to be able to
agree on a consensus opinion on this subject.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org