JDK-8057113 : (fs) Path should have a method to obtain the filename extension
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.nio
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2014-09-02
  • Updated: 2023-09-05
  • Resolved: 2022-11-01
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.
JDK 20
20 b22Fixed
Related Reports
CSR :  
JDK-8260738 - (fs) Path should have a method to obtain the filename extension
Duplicate :  
JDK-4224436 - File.{check,get,has}Extension() to access filename extension
Relates :  
JDK-8297814 - (fs) Re-visit Path.getExtension return value
Relates :  
JDK-8298303 - (fs) temporarily remove Path.getExtension
Relates :  
JDK-4224436 - File.{check,get,has}Extension() to access filename extension
Relates :  
JDK-8298318 - (fs) APIs for handling filename extensions
Sub Tasks
JDK-8297160 :  
Release Note: The new method Path::getExtension returns the file’s extension - Resolved
Description
For some reason Path.getFileName() returns a Path, not a String.  This makes it clumsy to see if the filename has a particular extension, since you need an ugly .toString() to get the string of the Path before you can call .endsWith.

It would be nicer if there was a recognition that manipulating extensions was a common operations on many path objects, and if there was API for that.
Comments
This change was backed out in JDK-8298303.
05-09-2023
Changeset: 50d91a31 Author: Brian Burkhalter <bpb@openjdk.org> Date: 2022-11-01 21:35:54 +0000 URL: https://git.openjdk.org/jdk/commit/50d91a31d495adf8e189d0188918f4ff22f93876
01-11-2022
See also Guava's MoreFiles::getFileExtension and MoreFiles::getNameWithoutExtension: https://guava.dev/releases/30.1.1-jre/api/docs/com/google/common/io/MoreFiles.html#getFileExtension(java.nio.file.Path)
30-06-2022
A pull request was submitted for review. URL: https://git.openjdk.java.net/jdk/pull/8066 Date: 2022-03-31 20:28:03 +0000
31-03-2022
From the description: > This makes it clumsy to see if the filename has a particular extension I would say that it's more of an easy trap to fall into, rather than just "clumsy". Is it clumsy? Sure it is. But only after you have figured out what happens. Before that, it's a head-scratcher and debugging pain. It's so natural to write this in an IDE that has autocompletion, that you are almost guaranteed to do it: getFileName().endsWith(".java") Where in fact you should've written getFileName().toString().endsWith(".java")
02-09-2021
I am strictly against support for file extensions as part of the Paths API. The reason is that a Path is an abstraction of the actual file system. I am not aware of any technical support of file extensions as part of any broadly used file system these days. Yes, you can use file extensions as part of the file name, but the file system itself does not make any special use of it other than storing the information itself. There is no actual enforced syntax, and even the existence of a single dot is neither restricted nor enforced - you can have any number of dots even zero, so where does a file extension actually start and end on NTFS, Ext3, etc.? File extensions are an paradigm existing in the user's mind only, but not in the file system actually. Hence, this should never get mixed into this abstraction framework! If support for file name parsing and construction of intra-path-syntax is wanted, then a separate utility class should do that, which is in no way mixed into the Paths API and I doubt it is actually really a Java topic at all!
03-06-2021
getFileName has to return a Path as converting to a String causes the underlying representation to be lost (important for example then the underlying representation is bytes). Support for file extensions has been discussed several times, just has bubbled up the list with a good proposal yet. Prototypes in the past included a getExtension method to return the extension as a String and a split method to return a String[] with the file name and extension as Strings. One area of difficulty is defining what an extension means as it's just a convention on most platforms and there isn't one definition that covers all the corner cases that come up with file names that start with or have repeating dots in their name.
19-02-2018