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.
On Thu, Jan 8, 2026, 5:50 AM Anthony Vanelverdinghe <[email protected]>
wrote:
> On 1/8/2026 10:39 AM, Alan Bateman wrote:
> > On 08/01/2026 01:02, Brian Burkhalter wrote:
> >> We have had a bit of a race condition in this discussion, but at
> >> least there appears to be some agreement that deprecation alone (with
> >> some javadoc enhancement) is a good way to go.
> > It would be also be good to try again to get a handle on the use-cases
> > around the convention that we know as the "file extension". We've had
> > several failed attempts on this but I think you make good progress on
> > defining it at the last iteration. That is, I assume some temptation
> > to use endsWith(String) is just wanting to test if the string
> > representation has an interesting suffix.
> >
> > -Alan
> Alan is spot on here, and I'm wholeheartedly in favor of leaving the API
> untouched.
>
> What I believe is needed, is simply to:
> * add a method to get the file extension from a Path (people want to get
> the file extension from a Path, notice there's no method to do so,
> notice `endsWith(String)`, use that, eventually find out it doesn't work
> as they expected, and then blame `endsWith(String)`)
> * point out that the current APIs actually are intuitive (when a method
> is overloaded, I intuitively expect all overloads to behave in the same
> manner, except for a trivial conversion of their arguments to some
> canonical form. This is exactly the case here)
> * remind people to read the Javadoc (the Javadoc of these methods is
> crystal clear on their behavior)
>
> The existing methods are useful (fwiw, in my codebases all uses of
> `Path::endsWith` invoke the `String` overload) and have many uses in
> existing codebases (as they've existed for nearly 15 years). And again,
> the actual issue is people expecting methods to behave as needed in the
> context of their actual use case (here, in 99% of the cases: testing the
> file extension), without verifying their expectations by reading the
> Javadoc.
>
> Deprecating these methods is also a sure-fire way to have people
> introduce subtle bugs in their codebases, as they'd likely "fix" the
> deprecations by replacing `path.endsWith("other")` with
> `path.endsWith(Path.of("other"))`.
>
> Adding `Path.pathString{ends,starts}With(String)` would be a mistake, I
> believe. One of the things that makes `Path` such a fine API, is that it
> cleanly abstracts the OS-specific file separator. These methods would
> break that abstraction and you'd end up with things like
> `Path.of("foo\bar").pathStringStartsWith("foo/bar")` and either way
> you'd have people complaining that its behavior is unintuitive (i.e.,
> some people would expect this to return `true`, others `false`).
>
> Anthony
>
