Path.startsWith() etc

Benedict Elliott Smith lists at
Tue Nov 30 04:32:14 PST 2010

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

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> 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...

More information about the nio-dev mailing list