Can we deprecate Path.endsWith(String)?

[David Alayachew]

Sorry to revive this thread after all this time. Missed the emails somehow.

A file extension method would be ideal. Didn't know that was on the table.

As for deprecations, I still think all 4 methods should be deprecated. This
path variants are kind of ok, but the String variants are just too
deceptively named.

I think Rob Spoor hit it on the head with this quote.

> Perhaps both can be added?
>
> Path.{start,end}sWithString would default to calling
> toString().{start,end}sWith(arg) and
> Path.{start,end}sWithPath would default to calling
> {start,end}sWith(arg). The latter could default to
> calling {start,end}sWith(getFileSystem().getPath(arg))
> but then custom implementations that do something else
> (in addition) may not work as expected.

Doing it this way, we can have (start|end)sWithPath() have both String and
Path overloads with no ambiguity.

And (start|end)sWithString() doesn't obviate the need for a file extension
method/API. It would just be a good enough stop gap in the meantime.

Out of curiosity, why was the old commit for file extension pulled out? I
only see the commit hash, I don't know how to look that up.

Thank you all again for your time and consideration.
David Alayachew

On Thu, Sep 18, 2025 at 5:12 PM Pavel Rappo <pavel.rappo at gmail.com> wrote:

> On Thu, Sep 18, 2025 at 7:08 PM Brian Burkhalter
> <brian.burkhalter at oracle.com> wrote:
>
> <snip>
>
> > I have filed an issue to improve the specification of this method
> somehow:
> >
> > https://bugs.openjdk.org/browse/JDK-8368007
> >
>
> Personally, a better spec wouldn't have helped me avoid the trap. The
> spec is already clear. I think it's the combination of the method's
> name and the argument type that is misleading.
>
> I think I learned about this method by scrolling autocompletion
> suggestions in my IDE. The method seemed to fit my need exactly. Of
> course, I quickly learned that I was wrong, but somehow kept falling
> into the same trap. Not sure how representative my experience in this
> case is, though.
>
> Deprecation would flag the method in the IDE and help avoid the trap.
> But eventually, it would be good to also have the file extension
> functionality.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20251102/1053357b/attachment-0001.htm>