<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 1/7/26 12:34 PM, Brian Burkhalter
wrote:<br>
</div>
<blockquote type="cite" cite="mid:873180DD-3178-43EB-BB6E-7A9EB170B05B@oracle.com">
<div>Resuscitating this discussion thread from last year ...</div>
<div><br>
</div>
<div>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:</div>
<div><br>
</div>
<div>* Path.{ends,starts}With(String) ->
Path.{ends,starts}WithString(String)</div>
<div>* Path.{ends,starts}With(Path) ->
Path.{ends,starts}WithPath(Path)</div>
</blockquote>
<p>My experience is that deprecation for the purposes of renaming
doesn't work very well. I don't think we're intending to remove
the old APIs, so they'd remain, so "renaming" would merely be the
addition of new APIs with similar names. This would just make
things more confusing.</p>
<p>The main problem is that Path.{ends,starts}With(String) is
confusing and misleading, so let's focus on that.<br>
</p>
<blockquote type="cite" cite="mid:873180DD-3178-43EB-BB6E-7A9EB170B05B@oracle.com">
<div>Among doubtlessly many others, one alternative is</div>
<div><br>
</div>
<div>1. Leave Path.{ends,starts}With(Path) unchanged</div>
</blockquote>
<p>This makes sense. I haven't seen any evidence that this is a
problem if one is already working in the Path domain.</p>
<blockquote type="cite" cite="mid:873180DD-3178-43EB-BB6E-7A9EB170B05B@oracle.com">
<div>2. Deprecate Path.{ends,starts}With(String)<br>
</div>
</blockquote>
<p>This is the confusing one, so yes, deprecate this (not for
removal). It's an open question regarding what the deprecation
text should recommend be used instead. Perhaps some of the
discussion below will resolve this.<br>
</p>
<blockquote type="cite" cite="mid:873180DD-3178-43EB-BB6E-7A9EB170B05B@oracle.com">
<div>3. Add Path.pathString{ends,starts}With(String)</div>
<div><br>
</div>
<div>where "pathstring" in effect implies the value of
Path.toString().</div>
</blockquote>
<p>Before we start adding new APIs, I think we should consider which
use cases we think we want to support. The methods take a string
argument, and the two cases are whether the operation is performed
on Paths and Path segments or whether the operation is performed
in terms of Strings.<br>
</p>
<p>For brevity I'll just use "EW" to represent the "endsWith"
operation in either domain, but the analysis applies equally to
the "startsWith" operation.<br>
</p>
<p>Suppose we start off with</p>
<p> <font face="monospace">var path = Path.of("/one/two/three");</font></p>
<p>The cases are:<br>
</p>
<p>a) Path domain. The code <font face="monospace">path.EW(string)</font>
is equivalent to</p>
<p><font face="monospace">
path.endsWith(path.getFileSystem().getPath(string))<br>
// note, this is Path.endsWith(Path)<br>
</font></p>
<p>and thus we have<br>
</p>
<p><font face="monospace"> path.EW("/two/three") ==> false<br>
path.EW("two/three") ==> true</font></p>
<p>b) String domain. The code <font face="monospace">path.EW(string)</font>
is equivalent to</p>
<p><font face="monospace"> path.toString().endsWith(string)<br>
// note, this is String.endsWith(String)<br>
</font></p>
<p>and thus we have</p>
<p><font face="monospace"> path.EW("/two/three") ==> true<br>
path.EW("two/three") ==> true</font></p>
<p>=====</p>
<p>I'm not convinced we need any new APIs at all. It seems likely
that many people want to perform the string-based endsWith()
operation, in which case maybe it's best to be explicit and
convert the path to a string using toString() before doing that.
Adding a deprecation for Path.endsWith(String) should warn people
not to use this method for the string-domain case.</p>
<p>If you want to perform this operation in the Path domain, maybe
it's best to be explicit about it. If you're writing library code
that wants to be very general, then you probably have the relevant
FileSystem in a local variable already, and you might construct
Path objects explicitly before invoking the endsWith(Path)
operation. Using string literals directly, and having them
implicitly be converted to Path objects, seems like it easily
leads to subtle problems (such as the difference in behavior
between my "/two/three" and "two/three" examples above.) So, maybe
being explicit is better, even if it is more verbose and less
convenient.<br>
</p>
<p>If you're writing an application that uses the default FileSystem
everywhere, and you really want to perform a Path-based operation,
you can just slap Path.of() around your string literal and move
on. I don't think we need another method to handle this case. <br>
</p>
<p>So, maybe do (1) and (2) but omit (3). This boils down to just
deprecating endsWith(String) and startsWith(String).</p>
<p>s'marks<br>
</p>
<blockquote type="cite" cite="mid:873180DD-3178-43EB-BB6E-7A9EB170B05B@oracle.com">
<div><br>
</div>
<div>Comments?</div>
<div><br>
</div>
<div>Brian</div>
<div><br>
<blockquote type="cite">
<div>On Nov 2, 2025, at 3:35 PM, David Alayachew
<a class="moz-txt-link-rfc2396E" href="mailto:davidalayachew@gmail.com"><davidalayachew@gmail.com></a> wrote:</div>
<br class="Apple-interchange-newline">
<div>
<div class="gmail_default" style="caret-color: rgb(0, 0, 0); font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: monospace;">
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.</div>
<div class="gmail_default" style="caret-color: rgb(0, 0, 0); font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: monospace;">
<br>
</div>
<div class="gmail_default" style="caret-color: rgb(0, 0, 0); font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: monospace;">
I think Rob Spoor hit it on the head with this quote.</div>
<div class="gmail_default" style="caret-color: rgb(0, 0, 0); font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: monospace;">
<br>
</div>
<div class="gmail_default" style="caret-color: rgb(0, 0, 0); font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: monospace;">
> Perhaps both can be added?</div>
<div class="gmail_default" style="caret-color: rgb(0, 0, 0); font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: monospace;">
> </div>
<div class="gmail_default" style="caret-color: rgb(0, 0, 0); font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: monospace;">
> Path.{start,end}sWithString would default to calling</div>
<div class="gmail_default" style="caret-color: rgb(0, 0, 0); font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: monospace;">
> toString().{start,end}sWith(arg) and</div>
<div class="gmail_default" style="caret-color: rgb(0, 0, 0); font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: monospace;">
> Path.{start,end}sWithPath would default to calling</div>
<div class="gmail_default" style="caret-color: rgb(0, 0, 0); font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: monospace;">
> {start,end}sWith(arg). The latter could default to</div>
<div class="gmail_default" style="caret-color: rgb(0, 0, 0); font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: monospace;">
> calling
{start,end}sWith(getFileSystem().getPath(arg))</div>
<div class="gmail_default" style="caret-color: rgb(0, 0, 0); font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: monospace;">
> but then custom implementations that do something
else</div>
<div class="gmail_default" style="caret-color: rgb(0, 0, 0); font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: monospace;">
> (in addition) may not work as expected.</div>
<div class="gmail_default" style="caret-color: rgb(0, 0, 0); font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: monospace;">
<br>
</div>
<div class="gmail_default" style="caret-color: rgb(0, 0, 0); font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: monospace;">
Doing it this way, we can have (start|end)sWithPath() have
both String and Path overloads with no ambiguity.</div>
</div>
</blockquote>
</div>
<br>
</blockquote>
</body>
</html>