How to .resolve*() and .relativize() Paths which are not issued from the same FileSystem?

[Francis Galiegue]

Hello again,

On Sun, Nov 30, 2014 at 9:43 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
[...]
>>
>> And this reminds me of another question I had about that: why does the
>> Path API make a difference between having a root component and being
>> absolute? In other words, is there possibly a case where a Path is
>> absolute but has no root component or the reverse?
>
> The most obvious example is on Windows where paths such "C:foo" and "\foo"
> have root components but are not absolute paths.
>

OK, that makes sense -- however I didn't know that the first path was
valid at all; or even whether it can represent anything at all...

>
>> :
>>
>> I don't see how this is a problem since the goal is to have a path
>> suitable for the filesystem of p2; I mean, if you resolve against a
>> string, you are supposed to create a path against the target
>> filesystem, right? As such why would the internal representation of p1
>> matter?
>>
> Converting to a String might be lossy, esp. if the internal representation
> is bytes. So if p1 and p2 are associated with the same file system provider
> then you can preserve the internal representation. We don't have a solution
> for this when converting name elements from one file system provider to
> another.
>

Well, if you cannot convert from/to the necessary byte array, you are
supposed to throw an InvalidPathException, correct? In UnixPath I see
that a Charset{De,En}coder is used for these purposes with a
CodingErrorAction of REPORT.

Well, while I'm at it, yet another question... This time this is the
doc of .resolveSibling(): "[...]If this path does not have a parent
path, or other is absolute, then this method returns other. If other
is an empty path then this method returns this path's parent, or where
this path doesn't have a parent, the empty path."

The last part is rather confusing: "or where this path doesn't have a
parent, the empty path". This scenario is in fact already covered by
the first part: since the path does not have a parent, other is
returned -- even if other is the empty path.

And there's even a contradiction there: what is "the empty path"? An
empty path attached to the file system of "path" or "other"? On Linux,
it returns "other" unconditionally, which says it's the first part
which takes precedence.

So, should this last part of the documentation be removed?


(I'm sure I am missing another question which I had... Ahwell. Sorry
for the trouble!)

-- 
Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge
JSON Schema in Java: http://json-schema-validator.herokuapp.com
Parsers in pure Java: https://github.com/parboiled1/grappa (redde
Caesaris: https://github.com/sirthias)