Path.startsWith() etc

[Benedict Elliott Smith]

I disagree that this is inconsistent behaviour for methods which perform a
simple test - paths from different providers cannot possibly be prefixes of
each other, so returning false seems perfectly safe and sensible - and in
keeping with (for instance) Object equality, which will ordinarily return
false when comparing objects of a different type, rather than a
ClassCastException or similar.

I encountered this because I have implemented a number of custom file system
providers for use in an internal application for replicating file changes
between different locations over a number of different protocols. Certain
locations only require changes from certain prefixes of other locations, and
ideally this would be a straightforward startsWith() test, but instead I
have to first get hold of the FileSystemProvider and test they are equal,
which feels like a bad way to go about checking this. The Path objects
themselves can more easily do this with e.g. an instanceof test, which they
perform anyway.

I can understand why methods composing/acting on two Path objects of a
different type would fail, but I don't really see why simple tests should
not.

Also, whilst on the topic, I wonder about the sense of having *any* provider
for *relative* paths. Conceptually paths whose roots are not a member of the
set of roots of all known file systems really have no place being
constrained in anyway. I would expect to be able to obtain a relative path
from one file system and compose it with one from another without any errors
occurring. As it is this is very messy, and requires creating a path
completely in one file system, converting it to a String and passing it into
a different provider to obtain a new Path.



On 30 November 2010 11:58, Alan Bateman <Alan.Bateman at oracle.com> wrote:

>  Benedict Elliott Smith wrote:
>
> Hi,
>
>  The UnixPath implementation behaves rather annoyingly when the argument
> is a different type of Path.
>
>  Currently a java.nio.file.ProviderMismatchException is thrown, but for
> ease of use it would be preferable (to my mind) to simply return false.
>
> The exception is expected:
>
> "Unless otherwise noted, invoking a method of any class or interface in
> this package created by one provider with a parameter that is an object
> created by another provider, will throw ProviderMismatchException"
>
> Changing things so that some methods, like startsWith, return false might
> be inconsistent. I'm curious how you ran into this as I assume there must be
> a bug somewhere. Another thing to mention is that we are currently missing
> startsWith(String), endsWith(String), something that has come up a few
> times.
>
>
>
>  Given that the new Path APIs have been designed to make using different
> providers interchangeably and uniformly, does it seem sensible to make as
> many methods as possible "safe" with respect to interaction between provider
> types.
>
> Although the API allows for different providers there is no requirement
> that these providers be interoperable (as one provider will not know
> anything about the representation of objects associated with other
> providers).
>
> -Alan.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20101130/f6fb10fd/attachment.html