Can we deprecate Path.endsWith(String)?

[David Alayachew]

Hello @core-libs-dev <core-libs-dev at openjdk.org>,

I have frequently run into the following pothole.

Imagine the following directory setup.

root/folderA/fileX.java
root/folderB/fileY.js
root/folderC/fileZ.html

In this directory, let's say that we run the following code.

Files
.walk(Path.of("root"))
.filter(path -> path.endsWith("html"))
.forEach(System.out::println)
;

One would expect only fileZ.html to be printed out, but nothing does. The
reason why is because path.endsWith(String) is effectively an alias for
path.endsWith(Path.of(String)). The confusion being that
Path.of(someString) is looking for a file or a directory. Thus, since there
is neither a file nor a folder called "html", the stream prints out nothing.

This a very easy pothole to fall into, as the method name endsWith is the
same as the one for String, thus, people will easily mix it up. And worse
yet, depending on what they test with, they can easily confuse themselves
into thinking they are good. For example, if I had done "fileZ.html" as my
endsWith, I would have returned exactly what was expected, causing me to be
misled.

And as a cherry on the top, the syntactic benefit of this method is very
little. Wrapping your string in a Path.of() means that you fall under the
Path.endsWith(Path) overload, which is more explicit what it does. And at
the very least, should give pause to the developer thinking it is doing
String comparison, as they have to wrap their String in a Path, causing a
moment to think.

So, since this is a low value method and it causes high confusion, I vote
that we deprecate it.

Thoughts?

Thank you for your time.
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250910/e49e60ca/attachment-0001.htm>