<div dir="ltr"><div class="gmail_default" style="font-family:monospace">Sorry to revive this thread after all this time. Missed the emails somehow.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">A file extension method would be ideal. Didn't know that was on the table.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="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="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">I think Rob Spoor hit it on the head with this quote.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">> Perhaps both can be added?</div><div class="gmail_default" style="font-family:monospace">> </div><div class="gmail_default" style="font-family:monospace">> Path.{start,end}sWithString would default to calling</div><div class="gmail_default" style="font-family:monospace">> toString().{start,end}sWith(arg) and</div><div class="gmail_default" style="font-family:monospace">> Path.{start,end}sWithPath would default to calling</div><div class="gmail_default" style="font-family:monospace">> {start,end}sWith(arg). The latter could default to</div><div class="gmail_default" style="font-family:monospace">> calling {start,end}sWith(getFileSystem().getPath(arg))</div><div class="gmail_default" style="font-family:monospace">> but then custom implementations that do something else</div><div class="gmail_default" style="font-family:monospace">> (in addition) may not work as expected.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">Doing it this way, we can have (start|end)sWithPath() have both String and Path overloads with no ambiguity.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">And (start|end)sWithString() doesn't obviate the need for a file extension method/API. It would just be a good enough stop gap in the meantime.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">Out of curiosity, why was the old commit for file extension pulled out? I only see the commit hash, I don't know how to look that up.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">Thank you all again for your time and consideration.</div><div class="gmail_default" style="font-family:monospace">David Alayachew</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 18, 2025 at 5:12 PM Pavel Rappo <<a href="mailto:pavel.rappo@gmail.com" target="_blank">pavel.rappo@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, Sep 18, 2025 at 7:08 PM Brian Burkhalter<br>
<<a href="mailto:brian.burkhalter@oracle.com" target="_blank">brian.burkhalter@oracle.com</a>> wrote:<br>
<br>
<snip><br>
<br>
> I have filed an issue to improve the specification of this method somehow:<br>
><br>
> <a href="https://bugs.openjdk.org/browse/JDK-8368007" rel="noreferrer" target="_blank">https://bugs.openjdk.org/browse/JDK-8368007</a><br>
><br>
<br>
Personally, a better spec wouldn't have helped me avoid the trap. The<br>
spec is already clear. I think it's the combination of the method's<br>
name and the argument type that is misleading.<br>
<br>
I think I learned about this method by scrolling autocompletion<br>
suggestions in my IDE. The method seemed to fit my need exactly. Of<br>
course, I quickly learned that I was wrong, but somehow kept falling<br>
into the same trap. Not sure how representative my experience in this<br>
case is, though.<br>
<br>
Deprecation would flag the method in the IDE and help avoid the trap.<br>
But eventually, it would be good to also have the file extension<br>
functionality.<br>
</blockquote></div>