Can we deprecate Path.endsWith(String)?

[David Alayachew]

Oh yes, agreed -- if we were going to do this, can't just be this method.
So there is the startsWith method, for example.

If we are going down the documentation route, then I'd like a simple
example added to the javadocs for both startsWith and endsWith that show
what this would and would not match. Not only will this clear up my
ambiguity, but there might be a few corners of this api worth showing by
example.

For example, I had a root path specified by Path.of("."), and when I tried
to use the string overload of starts with (the way it was intended to be
used), it actually failed because I failed to add the ./ at the front.

If we don't want to add this stuff, that's fine. The dev will figure it out
eventually. I just keep falling into this hole, so I figured this would
make a useful experience report. And if nothing else, then this will help
for designing future api's.

Thanks for the help.
David Alayachew

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

> Hello David,
>
> On Sep 10, 2025, at 1:28 PM, David Alayachew <davidalayachew at gmail.com>
> wrote:
>
> 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.
>
>
> There are a number of methods in Path which are the same except for
> String- vs. Path-valued parameters. I’m not sure we’d want to deprecate
> just this one although I do see your point. Perhaps some additional
> disambiguating verbiage in the endsWith(String) specification would help?
>
> Brian
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250910/6ec460ed/attachment.htm>