URI issue

[Alan Bateman]

Christian Schlichtherle wrote:
> 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(*).
>   
If URIs u1 and u2 are equal then it doesn't mean that their toString 
methods will yield equal Strings. I think this is the issue that you are 
running into it. In the above then file:/C:/foo/bar is equal to 
file:///C:/foo/bar but because of the way the URIs are created, their 
toString methods yield non equal Strings.

In any case, the reason that the default provider creates the URI from 
the string "file:///C:/foo/" is so that it is interoperable with native 
applications and follows the syntax for URIs on Windows.

-Alan.