Can we deprecate Path.endsWith(String)?

[Brian Burkhalter]

Resuscitating  this discussion thread from last year ...

To summarize my rereading of the thread, there is good agreement that Path.{ends,starts}With(String) should be deprecated and replaced with something else, perhaps Path.{ends,starts}WithString(String). There was also a parallel suggestion that Path.{ends,starts}With(Path) be deprecated in favor of Path.{ends,starts}WithPath(Path). Thus:

* Path.{ends,starts}With(String) -> Path.{ends,starts}WithString(String)
* Path.{ends,starts}With(Path) -> Path.{ends,starts}WithPath(Path)

Among doubtlessly many others, one alternative is

1. Leave Path.{ends,starts}With(Path) unchanged
2. Deprecate Path.{ends,starts}With(String)
3. Add Path.pathString{ends,starts}With(String)

where "pathstring" in effect implies the value of Path.toString().

Comments?

Brian

On Nov 2, 2025, at 3:35 PM, David Alayachew <davidalayachew at gmail.com> wrote:

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20260107/0e221d26/attachment-0001.htm>