<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Benedict Elliott Smith wrote:
<blockquote
 cite="mid:AANLkTimVq6QUnCLhMcjA34HqpOQUd=HP53wLd4N34EUJ@mail.gmail.com"
 type="cite">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.
  <div><br>
  </div>
  <div>I encountered this because I have implemented a number of custom
file system providers for use in an internal application
for&nbsp;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.</div>
</blockquote>
So it is a virtual file system provider that is examining the path or
is the application?<br>
<br>
<br>
<blockquote
 cite="mid:AANLkTimVq6QUnCLhMcjA34HqpOQUd=HP53wLd4N34EUJ@mail.gmail.com"
 type="cite">
  <div><br>
  </div>
  <div>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.</div>
  <div><br>
  </div>
  <div>Also, whilst on the topic, I wonder about the sense of having <i>any</i>&nbsp;provider
for <i>relative</i> 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.<br>
  </div>
</blockquote>
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).<br>
<br>
-Alan<br>
</body>
</html>