URI issue

[Christian Schlichtherle]

Hi Alan,

I just came across an issue with the URIs created by Paths.get(String first,
String. more).

On Windows if the current directory is C:/foo, then

assert "file:///C:/".equals(Paths.get("/").toUri().toString());
assert "file:///C:/foo/".equals(Paths.get("").toUri().toString());

Now the use of the empty authority is problematic because the URI class has
several issues with it:

assert null == URI.create("file:///C:/foo/").getAuthority(); // expected ""
!
assert
"file:/C:/foo/bar".equals(URI.create("file:///C:/foo/").resolve("bar").toStr
ing()); // expected "file:///C:/foo/bar"

As you can see, the URI class "optimizes" away the superfluous empty
authority returned by Paths.get(*).

However, this violates its identity provision that for any hierarchical URI
u,

assert u.equals(new URI(u.getScheme(), u.getAuthority(), u.getPath(),
u.getQuery(), u.getFragment())); // will fail with URI.create("file:///C:/")

See http://download.oracle.com/javase/7/docs/api/java/net/URI.html

All in all, the superfluous empty authority should be avoided in order not
to get in trouble. I came across this in the unit tests for my
TFileSystemProvider class. My workaround for now is to rewrite the URI
returned by Paths.get(*).


Regards,
Christian