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
