RFR 8057113: (fs) Path should have a method to test the filename extension

Remi Forax forax at univ-mlv.fr
Wed Feb 14 08:24:06 UTC 2018


I agree with Alan,
getExtension() is better than hasExtension() which solidify how the extension matching is done, the user code should decide how the matching is done.

for the definition, everything after the last '.' is good for me.

Rémi

----- Mail original -----
> De: "Alan Bateman" <Alan.Bateman at oracle.com>
> À: "Brian Burkhalter" <brian.burkhalter at oracle.com>, "nio-dev" <nio-dev at openjdk.java.net>
> Envoyé: Mercredi 14 Février 2018 08:38:56
> Objet: Re: RFR 8057113: (fs) Path should have a method to test the filename extension

> On 14/02/2018 04:23, Brian Burkhalter wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8057113
>> http://cr.openjdk.java.net/~bpb/8057113/webrev.00/
>>
>> As a first cut at this problem, this patch would add a new method hasExtension()
>> to the java.nio.file.Path interface with a default implementation. The
>> implementation is overridden only by UnixPath. ZipPath does not override it but
>> perhaps should.
>>
>> Regression tests passed on all platforms both with and without the UnixPath
>> changes (in order to verify the default implementation on all platforms).
>>
>> Obviously a CSR will be in order.
> I don't think this is the right API to add. While it has issues, I think
> we need to look at getExtension that returns as String. An important
> point is that the API will need to define what an extension is because
> it currently doesn't have this notion.
> 
> -Alan


More information about the nio-dev mailing list