This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 214131 - JAR URLs using / vs. /// in file component are not equal
Summary: JAR URLs using / vs. /// in file component are not equal
Status: RESOLVED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: Filesystems (show other bugs)
Version: 7.2
Hardware: PC Linux
: P2 normal (vote)
Assignee: Jesse Glick
URL:
Keywords:
: 214068 214145 214146 (view as bug list)
Depends on:
Blocks: 213562
  Show dependency tree
 
Reported: 2012-06-13 13:18 UTC by Tomas Zezula
Modified: 2012-06-14 21:55 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Tomas Zezula 2012-06-13 13:18:00 UTC 
The following jar URLs are not equal:

jar:file:/opt/icedtea-bin-7.2.1/jre/lib/rt.jar!/
jar:file:///opt/icedtea-bin-7.2.1/jre/lib/rt.jar!/
Comment 1 Tomas Zezula 2012-06-13 13:56:18 UTC 
*** Bug 214068 has been marked as a duplicate of this bug. ***
Comment 2 Jesse Glick 2012-06-13 15:52:24 UTC 
core-main #6b283f46deed
Comment 3 Jan Lahoda 2012-06-13 16:31:46 UTC 
*** Bug 214145 has been marked as a duplicate of this bug. ***
Comment 4 Vladimir Riha 2012-06-13 16:47:57 UTC 
*** Bug 214146 has been marked as a duplicate of this bug. ***
Comment 5 Quality Engineering 2012-06-14 06:07:49 UTC 
Integrated into 'main-golden', will be available in build *201206140001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/6b283f46deed
User: Jesse Glick <jglick@netbeans.org>
Log: #214131: JAR URLs using / vs. /// in file component are not equal
Comment 6 Jesse Glick 2012-06-14 21:55:24 UTC 
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.