[Request for Comments] File extension redux

[Roger Riggs]

Hi Brian,

First the intuition and then the rationale.

Intuition: the extension does not include the period '.' learned from 
years of working with existing systems, both shell and programming 
languages with file apis.

Second: In trying to make Path.getExtension() handle all of the use 
cases possible, it makes some of them more difficult.  In particular, 
the cases for removing or replacing the extension are easier to do with 
a method for that purpose. It is easier to explain using a 
Path.removeExtension() method than to explain how to convert the path to 
a string and then remove some number of characters from the end and 
recreate the Path.

Rationale:

  * Other Java libraries that provide path name utilities do not include
    the dot as part of the extension; (Guava and Apache Commons). A
    mismatch with them (and other common Java libraries) creates
    friction and room to make mistakes in conversions between different
    representations.
  * The no-dot representation works just fine except in the case of
    trailing dot, which is quite uncommon in practice.
  * The APIs provided should do what the programmer needs to do, not be
    APIs from which the programmer can create the API they need and
    still avoid an explosion of APIs for narrow use cases.
  * Extensions are used in many ways, from switch statements to keys in
    maps to simple if/then/else; some are hard coded and others are
    configured or loaded as plugins. The semantics should be simple and
    direct.

For 1) and 3) I would say that both "foo" or "foo." have an empty ("") 
extension.
Providing a removeExtension() or replaceExtension(String) method can 
embed the edge case handling and make the API easy to use without having 
to burden the Path.getExtension() method with a model that includes that 
complexity.

Regards, Roger


On 10/10/23 2:31 PM, Brian Burkhalter wrote:
> I would like to resurrect this topic which has languished for quite a 
> while now. It was discussed for probably decades before my involvement 
> with it. A brief outline of its most recent history is included below. 
> The essence is that it would be good to add a 
> java.nio.file.Path.getExtension method, and possibly one or more 
> companion methods. General comments on the topic are welcome 
> regardless of whether the included chronology is reviewed. Things to 
> consider include:
>
> 1) whether a getExtension method ever returns null;
> 2) whether a period character is included as the first character of 
> the returned extension;
> 3) whether the extension of “foo” (no dot) differs from that of “foo.” 
> (terminal dot).
>
> Thanks,
>
> Brian
>
> --- snip --- TL;DR --- snip ---
>
> [1] Feb. 2018
> Path.hasExtension was initially proposed but dropped in favor of 
> Path.getExtension. This method was for the most common cases equivalent to
>
> Path path = ...;
> String name = path.getFileName();
> String extension = name.substring(name.lastIndexOf(“.”) + 1);
>
> which is to say the extension is the portion of the file name string 
> after but not including the last period character (dot). This effort 
> faded out.
>
> [2] Apr. 2021 - Mar. 2022
> A pull request was proposed and culminated in the proposal of the Path 
> method
>
> String getExtension(String defaultExtension)
>
> where in the common case the extension is once again the portion of 
> the file name string after the last dot. For degenerate cases the 
> “defaultExtension” parameter would be returned.  This effort was 
> superseded by [3].
>
> [3] Mar. 2022 - Dec. 2022
>
> This pull request specified the Path method
>
> String getExtension()
>
> which in the common case returned the portion of the file name string 
> after the last dot, and in unusual cases either the empty string 
> (terminal dot) or null (no dot). For a time this proposal used 
> Optional but that was dropped as unwieldy. This PR was approved and 
> integrated.
>
> [4] Dec. 2022
>
> Due primarily to the undesirability of the possibility of a null 
> return value and the lateness of the integration in the development 
> cycle, the API added in [3] was backed out.
>
> [5] Dec. 22
>
> A new issue was filed to track the resumption of eventual work on this 
> topic. This issue suggested that the last dot be included in the 
> extension, e.g., the extension of “image.jpg” would be “.jpg” rather 
> than “jpg” and that the value returned by getExtension would never be 
> null. It also proposed a complementary method Path.removeExtension 
> which, together with Path.getExtension, would form an invariant
>
> Path path = ...;
> assert path.equals(path.removeExtension() + path.getExtension());
>
> which would obviate the need to handle a period character explicitly.
>
> [1] https://mail.openjdk.org/pipermail/nio-dev/2018-February/004716.html
> [2] https://github.com/openjdk/jdk/pull/2319
> [3] https://github.com/openjdk/jdk/pull/8066
> [4] https://github.com/openjdk/jdk/pull/11566
> [5] https://bugs.openjdk.org/browse/JDK-8298318
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20231010/9b47365c/attachment.htm>