Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of flamefew@gmail.com designates
 66.249.92.174 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=fgfjbnyhGGi2FV7GDMzGSa4rIVL2fOrXRO49cee5mcnEJs7IuVP2mEEgvYCZpJEziMr1af76HJDZ+xNFCclfnEzCBJOBOXvC20Kn22WvFeeXvYE7Oe7Qodewyk9iaaOQtSRPO6+KhCFUbCuaBb1AOcxBvxWQt3DhVZ2inq0fAbE=
Message-ID: <31cc37360607211330g3641704cqb5482689dee96c30@mail.gmail.com>
Date: Fri, 21 Jul 2006 13:30:38 -0700
From: "Henri Yandell" <flamefew@gmail.com>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Subject: Re: [finder] Switch from java.util.FileFilter to Commons IO's
 IOFileFilter
In-Reply-To: <55afdc850607211222p5381c44v3779c6ff0802c024@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <55afdc850607211222p5381c44v3779c6ff0802c024@mail.gmail.com>

Makes a lot of sense to me - +1.

On 7/21/06, Niall Pemberton <niall.pemberton@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