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

Tue Nov 28 17:56:08 UTC 2023

On Mon, 27 Nov 2023 23:39:57 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Filenames that start with "." introduce a number of special cases.
> "." and ".." are not just conventions but have strong semantics. [...]

Surely everyone agrees that neither `.` nor `..` have an extension.

> For other files that begin with ".", it is conventional to name the file using the entire string.

It is conventional *on OSes where a leading dot marks a file/directory as hidden*.
On such OSes, "hidden marker" has precedence over "file extension separator"
and so `.mp3` denotes a hidden file with base `mp3` and without extension.

However, a leading dot has no special meaning on Windows (and in the relevant APIs in both Guava and Apache Commons IO).
So on Windows, `.mp3` denotes an audio file with an empty base and an extension of `.mp3` (or `mp3`, if you will).

What I'm advocating, is that `getExtension()` must support both conventions, either implicitly (by returning an OS- and/or file system-specific result) or explicitly (by allowing the developer to specify the desired convention somehow).

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

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