Can we deprecate Path.endsWith(String)?

[Stuart Marks]

Let's not tie these two issues together.

The discussion clearly shows that the startsWith/endsWith(String) APIs are a trap 
that several people have fallen into. On that basis it should be deprecated. 
(Ordinarily, so as to emit a warning, and not for removal, so there won't be any 
compatibility issue.)

There is also no requirement that a new API be introduced to replace any deprecated 
API. As the earlier discussion in the thread shows, both the path-based and the 
string-based use cases can be written using existing APIs, somewhat less 
conveniently and more verbosely; but these constructs are much more explicit and so 
are preferable to the APIs to be deprecated. The deprecation text should steer 
people toward the preferred constructs.

It would indeed be nice to have a file extension API, but this has been discussed 
several times and has run aground each time for a variety of reasons. Tying these 
together will hold up the deprecation for no good reason.

Let's proceed with just the deprecation first and work on the file extension API 
separately.

s'marks

On 1/11/26 12:45 PM, David Alayachew wrote:
> Thanks for the response Anthony. Messages have been arriving out-of-order for me, 
> so I didn't see yours at the time of me writing that message.
>
> I think introducing the file extension API first, then gauging the need for a 
> deprecation before doing it is fine. Sounds like then that we are universally 
> agreed on the first step being to add the file extension API, yes?
>
> On Sun, Jan 11, 2026 at 2:06 PM Anthony Vanelverdinghe <anthonyv.be at outlook.com> 
> wrote:
>
>     I dissent. (Apparently my previous message wasn't clear.)
>
>     The right order of things is to first introduce a file extension API. Then see
>     if there's still complaints about `Path::endsWith(String)`. And only then, if
>     there are, consider taking action.
>
>     In my previous message I've already explained how these methods add real,
>     tangible value and actually are intuitive.
>     (Again, ask developers to guess how `A::foo(B)` behaves, given that both
>     `A::foo(A)` and `B::foo(B)` exist, and a large majority of them will
>     intuitively guess it converts its `b` argument to an instance of `A` and
>     passes it on to `A::foo(A)`. And their intuition would be correct in the case
>     of `Path::endsWith(String)`. That being said, I'll be the first to admit that
>     I've also made the mistake of attempting to use `Path::endsWith(String)` to
>     test the file extension.)
>
>     In hindsight, maybe `endsWithNames(String)` would've been a better choice, but
>     hindsight is 20/20.
>
>     Deprecating these methods now is premature. And deprecating them without
>     replacement methods would result in way more complaints than there have ever
>     been about `endsWith(String)`.
>
>     Anthony
>
>     On 1/11/2026 12:19 AM, David Alayachew wrote:
>>     Of course.
>>
>>     I see lots of approvals and not really any dissenters. Are we waiting for
>>     more responses? Or is there anything we can do to kick start this?
>>
>>     On Fri, Jan 9, 2026, 10:22 PM Brian Burkhalter <brian.burkhalter at oracle.com>
>>     wrote:
>>
>>         Thanks for the corroboration.
>>
>>>         On Jan 8, 2026, at 1:50 PM, David Alayachew <davidalayachew at gmail.com>
>>>         wrote:
>>>
>>>         Thanks for reviving this.
>>>
>>>         I am perfectly happy with the idea of deprecating the
>>>         Path.{start,ends}With(String), and then only add the file extension
>>>         method. Originally, I didn't know that new method was on the table, so I
>>>         suggested a rename. But the file extension api feels like the superior
>>>         solution.
>>>
>>>         10 times out of 10, if I am calling endsWith, the only time I am not
>>>         looking for "whole" path elements is when I am looking for a file
>>>         extension. In every other instance, the api does exactly what I expect
>>>         and want. And plus, something like looking for a file extension is
>>>         better off being explicit.
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20260112/51633f5a/attachment-0001.htm>