Can we deprecate Path.endsWith(String)?

[David Alayachew]

Hello @brian.burkhalter at oracle.com <brian.burkhalter at oracle.com>,

Yes exactly.

And I'm not trying to say that the method is underspecified -- the javadoc
is fairly clear.

I'm merely saying that this overload adds little value, while being a
tripping hazard for those thinking the name describes the obvious.

So, I'd like to deprecate the overload. Those who want the overload, just
use the suggestion in the javadocs.

On Wed, Sep 10, 2025, 4:07 PM Brian Burkhalter <brian.burkhalter at oracle.com>
wrote:

> Hello David,
>
> Redirecting to nio-dev.
>
> On Sep 10, 2025, at 12:01 PM, David Alayachew <davidalayachew at gmail.com>
> wrote:
>
> 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.
>
>
> The specification looks like it is pretty clear about the behavior,
> especially the implementation note in Path.endsWith(String)
> <https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/nio/file/Path.html#endsWith(java.lang.String)>
> :
>
> "The default implementation is equivalent for this path to:
>
>     endsWith(getFileSystem().getPath(other));"
>
> What you were expecting sounds like what would be given by
>
> .filter(path -> path.toString().endsWith("html”))
>
> or better
>
> .filter(path -> path.getFileName().toString().endsWith("html”))
>
> Is that correct?
>
> If we could eventually agree on how to handle file extensions, that would help here.
>
> Brian
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250910/10c3dfdc/attachment.htm>