[9] RFC on 8066943: (fs) Path.relativize() gives incorrect result for ".." on Windows

[Brian Burkhalter]

This issue https://bugs.openjdk.java.net/browse/JDK-8066943 looks to me to be “Not an Issue.” Using JDK 9 this test class

import java.nio.file.Path;
import java.nio.file.Paths;

public class JDK8066943 {

    public static void main(String[] args) throws Throwable {
        System.out.println(Paths.get("..").relativize(Paths.get("x")));

        System.out.println(Paths.get("").relativize(Paths.get("x")));
    }
}

prints

../x
x

on Unix (Mac OS 10.9.5 and Ubuntu 12.04) and

..\x
x

on Windows 7. Perhaps I am not understanding the spec but this behavior seems correct. The example in the issue description is

Paths.get("..").relativize(Paths.get("x”));

which seems logically similar to the rooted case of this example

“For example, if this path is "/a/b" and the given path is "/a/x" then the resulting relative path may be "../x”.”

from the spec of relativize() - http://download.java.net/jdk9/docs/api/java/nio/file/Path.html#relativize-java.nio.file.Path-. For the example in the first comment

Paths.get("").relativize(Paths.get("x”));

Paths.get(“”) is specified by http://download.java.net/jdk9/docs/api/java/nio/file/Paths.html#get-java.lang.String-java.lang.String...- to return the empty string so returning just “x” in this case seems appropriate.

It seems to me that this issue should be resolved as “Not an Issue” even though failing to reproduce the behavior in the description might justify “Cannot Reproduce.”

If my analysis is flawed please comment on what is incorrect.

Thanks,

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20150501/9d7da20b/attachment.html>