RFR: 8298318: (fs) APIs for handling filename extensions [v2]

[Roger Riggs]

On Mon, 20 Nov 2023 23:30:45 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add to `java.nio.file.Path` a method `getExtension` to retrieve the `Path`'s extension, and companion methods `removeExtension` and `addExtension`.
>
> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - 8298318: Correct type in path.getExtension spec
>  - Merge
>  - 8298318: (fs) APIs for handling filename extensions

Indeed, I was looking for more from those APIs than is there.
They have the simplest definition, but one that overlooks the various ways developers can carelessly cause themselves trouble. That lead to suggestions to avoid pitfalls.

Filenames that start with "." introduce a number of special cases. "." and ".." are not just conventions but have strong semantics. Considering either of them to have an extension is simple, but neither is useful.
Removing the extension from "..", leaves "." which is not the base of "..", its an entirely different thing.
Similarly, removing the extension of "." leaves the empty string, not a valid filename, though sometimes a no-op when concatenating strings.

For other files that begin with ".", it is conventional to name the file using the entire string. For example,
the directory ".git" is not a empty filename with a "git" extension; it is the full name of the directory.
Other dot files such as ".bashrc" or ".qtrc" are not related though both would have the same base (empty) if the leading "." was considered the start of an extension. 
More nuanced semantics for working with extensions may be more useful to developers and less open to misuse than the simplest literal parsing.

A scan of StackOverflow questions related to file extensions shows a wide variety of uses and suggestions for how to remove or extract extensions that have a more robust handling of the edge cases.

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

PR Comment: https://git.openjdk.org/jdk/pull/16226#issuecomment-1828810099