The following jar URLs are not equal:
*** Bug 214068 has been marked as a duplicate of this bug. ***
*** Bug 214145 has been marked as a duplicate of this bug. ***
*** Bug 214146 has been marked as a duplicate of this bug. ***
Integrated into 'main-golden', will be available in build *201206140001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Jesse Glick <firstname.lastname@example.org>
Log: #214131: JAR URLs using / vs. /// in file component are not equal
Alan Bateman explains why /// is used currently to differentiate URIs from those created by File.toURI, relating to encoding of non-ASCII pathname characters on Unix (which only Path.toUri escapes as octets):
"[Take] two shells, one with your locale set to zh_CN, the other with en_US for example. The only way for file URIs to be shared is if you encode the byte representation of the file path into the URI's path component. That will also allow you to share file URIs with native applications too.
"As it stands, Paths.get(URI) can handle file URIs created by Path.toUri or File.toURI. The File(URI) constructor can only reliably deal with URIs created by File.toURI. While file:/ and file:/// should be equivalent, we are using it to distinguish URIs created by java.io.File."
For NB rewrites file:/// into file:/ in Utilities.toURI, since producing a normalized URI is critical for common IDE functions such as classpath scanning and this affects everyone.
TBD whether there are implications of this decision for support of non-ASCII pathnames in the IDE, particularly in conjunction with external processes such as build tools and the web browser. It means that we use e.g. file:/tmp/hezky%20česky (on either JDK 6 or 7) rather than file:///tmp/hezky%20%C4%8Desky - though the former's toASCIIString() is indeed file:/tmp/hezky%20%C4%8Desky so if your system locale is UTF-8 then it is likely there would be no issue.