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

[David Lloyd]

...unless maybe the last '.' is the first character in the path, or
immediately follows a sequence of '.' that starts with the first
character in the path?

On Wed, Feb 14, 2018 at 2:24 AM, Remi Forax <forax at univ-mlv.fr> wrote:
> 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



-- 
- DML