[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-nio-dev
Subject:    Re: RFR: 8057113: (fs) Path should have a method to obtain the filename extension [v2]
From:       Alan Bateman <alanb () openjdk ! java ! net>
Date:       2021-01-31 12:42:45
Message-ID: hDqwPegKOU3l6SZsTwJUlm_I6Ump0VTH9wwzQc7oDfA=.17eadc4a-bc00-4bb3-9b8d-9117b16c32f7 () github ! com
[Download RAW message or body]

On Fri, 29 Jan 2021 23:13:55 GMT, Brian Burkhalter <bpb@openjdk.org> wrote:

> > Please review this proposed change to add a method \
> > `java.nio.file.Path.getExtension()`. This was initially discussed in the thread \
> > http://mail.openjdk.java.net/pipermail/nio-dev/2018-February/004716.html. This \
> > method would return the filename extension of the file name of the `Path`. The \
> > extension is defined to be the portion of the file name after the last dot \
> > `(‘.')`. 
> > The definitions of file extension for about fifteen platforms and languages were \
> > surveyed to try to find a reasonable compromise for the definition of extension. \
> > The most common definition was the last segment of the name including and after \
> > the last dot. The second definition omitted the last dot from the extension. \
> > Java-related platforms all exclude the last dot. (One divergent definition in the \
> > internal Java NIO method `AbstractFileTypeDetector.getExtension(String)` defines \
> > the extension as the part after the *first* dot.) 
> > All examined cases define the extension to be an empty string if it cannot be \
> > determined. None of these cases used `null` to represent an indeterminate \
> > extension. 
> > Little in the way of specifying behavior for special cases (consisting mainly of \
> > file names with one or more leading dots) was found. Most definitions concern \
> > themselves only with the last dot and what comes after it and ignore leading dots \
> > altogether. A few definitions ignore a leading dot at the zeroth character. The \
> > current proposal ignores a dot at character zero. 
> > The behavior of the proposed method for some example cases is as:
> > 
> > .              -> 
> > ..             -> 
> > .a.b           -> b
> > ......         -> 
> > .....a         -> a
> > ....a.b        -> b
> > ..foo          -> foo
> > test.rb        -> rb
> > a/b/d/test.rb  -> rb
> > .a/b/d/test.rb -> rb
> > foo.           -> 
> > test           -> 
> > .profile       -> 
> > .profile.sh    -> sh
> > ..foo          -> foo
> > .....foo       -> foo
> > .vimrc         -> 
> > test.          -> 
> > test..         -> 
> > test...        -> 
> > foo.tar.gz     -> gz
> > foo.bar.       -> 
> > image.jpg      -> jpg
> > music.mp3      -> mp3
> > video.mp4      -> mp4
> > document.txt   -> txt
> > 
> > If the specification can be agreed upon, then a test will be added to this PR and \
> > a corresponding CSR will be filed.
> 
> Brian Burkhalter has updated the pull request incrementally with one additional \
> commit since the last revision: 
> 8057113: Changes pursuant to PR conversation

src/java.base/share/classes/java/nio/file/Path.java line 259:

> 257:      * characters, does not contain a dot, only the first character is a dot,
> 258:      * or the last character is a dot.
> 259:      *

Thanks for bringing this one back. The survey and the current proposal seems \
reasonable.

The spec will need cover the case that the Path doesn't have a file name (getFileName \
can return null so I assume the prototype implementation will NPE in that case). Are \
you planning to return null or the empty String for this case?

"file name string" needs to be replaced with "the String representation of the file \
name". This is significant aspect of the proposal in that it aligns the method with \
toString rather than other operations that preserve the platform representation of \
the path.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2319


[prev in list] [next in list] [prev in thread] [next in thread]