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