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

[Brian Burkhalter]

Hi All and thanks for the comments.

On Feb 13, 2018, at 11:38 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> 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.

The idea here was to allow matching multiple versions of the extension which correspond to a given format, for example, jpg, JPG, and jpeg. This could be useful to avoid multiple calls for cases where the file content can correspond to multiple extensions.

> An important point is that the API will need to define what an extension is because it currently doesn't have this notion.

I defined it in the hasExtension() javadoc.

On Feb 14, 2018, at 12: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.

I suppose one could have both methods were there justification.

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


Good.

On Feb 14, 2018, at 6:11 AM, David Lloyd <david.lloyd at redhat.com> 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?


This case to me would map to no extension, i.e., either null or empty as one prefers.

On Feb 14, 2018, at 7:00 AM, Roger Riggs <Roger.Riggs at oracle.com> wrote:

> 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.


I read that before doing this. In the use case prompting this issue the foregoing definition would not work. I have always considered the extension to be that portion of the path after the last dot: "usually the extension is the substring which follows the last occurrence, if any, of the dot character” [1].

Thanks,

Brian

[1] https://en.wikipedia.org/wiki/Filename_extension
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20180214/8d23ae77/attachment.html>