JDK-8298318 : (fs) APIs for handling filename extensions
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.nio
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2022-12-07
  • Updated: 2024-09-19
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Duplicate :  
JDK-8297814 - (fs) Re-visit Path.getExtension return value
Relates :  
JDK-8298303 - (fs) temporarily remove Path.getExtension
Relates :  
JDK-8057113 - (fs) Path should have a method to obtain the filename extension
Description
APIs should be added that manipulate filename extensions.

There is a long history, but most recently the Path::getExtension API was added by JDK-8057113, a modification was proposed by JDK-8297814, and it was removed from JDK 20 by JDK-8298303 because changes were happening at the last minute. This RFE covers re-addition of the Path::getExtension API and a possible new and complementary API.

The Path::getExtension API as discussed in JDK-8297814 should be added pretty much as it was. Background and rationale is discussed in that bug report.

Investigation of use cases in support of that API revealed that a common operation is to remove the extension from a filename. A complementary API, for example named removeExtension(), could be added. This would use the exact same definition of extension as getExtension(), except that it would remove the extension instead of returning it. This is useful for cases where an application wants to replace a filename extension with a different one, or cases where an application wants to insert some unique value between the filename stem and its extension.

The invariant would be: concatenating the result of removeExtension() with getExtension() should equal the string form of Path::getFileName(), assuming the latter returns non-null.
Comments
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/16226 Date: 2023-10-17 19:52:14 +0000
09-07-2024
See JDK-8297814 for some rationale about the current proposal. Brief summary here. It's helpful always to return non-null, which avoids error-prone null checks. Creating an invariant where removeExtension() + getExtension() reconstructs the original string form avoids having to create special cases for the presence or absence of a dot. A common use case is to convert something like "foo.jpg" to "foo123.jpg", that is, to make a unique filename by inserting some unique string after the stem of the filename but before the dot. Including the dot in the return value from getExtension() makes this easier.
20-01-2023