Path.startsWith() etc

[Alan Bateman]

Benedict Elliott Smith wrote:
> 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.
So it is a virtual file system provider that is examining the path or is 
the application?


>
> 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.
I'm not aware of any general solution to that issue. Converting to 
Strings may be lossy but it's the only representation that each provider 
is required to be support (for exporting purposes).

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20101130/b8902e9a/attachment.html