RFR: 8057113: (fs) Path should have a method to obtain the filename extension [v3]
Brian Burkhalter
bpb at openjdk.java.net
Tue Feb 2 23:45:43 UTC 2021
On Mon, 1 Feb 2021 18:54:54 GMT, Roger Riggs <rriggs at openjdk.org> wrote:
>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>>
>> 8057113: Handle getFileName() == null; revise spec
>
> Marked as reviewed by rriggs (Reviewer).
**Alternate Specifications**
Alternate specifications are possible. Ignoring more precise naming, e.g., `getExtensionOrElseEmptyString()` for the original version above, some possible options are:
1. `String getExtension(`) returns the extension or the empty string if no extension found
2. `String getExtension()` returns the extension or `null` if no extension found
3. `String getExtension(String default)` returns the extension or `default` if no extension found (may be `null`)
4. `Optional<String> getExtension()` returns the extension, if any, contained in an `Optional`
Option 1 is that originally proposed. Option 2 is identical but returns null instead of the empty string if there is no extension. This is consistent with other methods in `Path` such as `getRoot()`, `getParent()`, and `getFileName()`. Option 3 allows the possibility to supply the value to be returned if no extension is found. Option 4 wraps the extension string or `null` in an `Optional`.
If one wanted to be able to retain the internal structure of the extension as a `Path`, then one could instead define two methods:
`Path Path.getExtension()`
`String Path.getExtensionString()`
as part of the point is the user not being obliged to call `toString()`. Here `getExtension()` would be implemented in the platform-specific `Path` classes, and `getExtensionString()` would be a default method in the `Path` interface.
In all cases, when the `Path` represents a root component, then the extension is indeterminate (empty or `null`, depending).
-------------
PR: https://git.openjdk.java.net/jdk/pull/2319
More information about the nio-dev
mailing list