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

[Roger Riggs]

Hi,

The java.nio.Files.probeContentType(Path) definition of extension should 
be consistent with this.
(Or vise-versa)

    AbstractFileTypeDetector.getExtension():
    * Returns the extension of a file name, specifically the portion of the
    * parameter string after the first dot.

I agree getExtension() is more generally useful and leave the matching 
to the caller.

$.02, Roger

On 2/14/2018 9:11 AM, David Lloyd wrote:
> ...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
>
>