On 08/21/2012 03:13 PM, Nicolas Lalevée wrote:
Or is there some code which rely on the broken behavior?
Not that I know of. See the various commented-out code blocks and "XXX" comments in this class; it has a long and messy history. I do not know whether the current code successfully works around all of File.toURL's failures.
Just beware that File.toUri is also broken for UNC paths. For a hint, [1] shows some analogous code in NetBeans which uses the better Path.toUri on JDK 7+, simplifying file:///path to file:/path; falling back to File.toUri with a manual file:////server/share/path -> file://server/share/path correction.
You may also need to be wary of non-ASCII characters in pathnames on operating systems not using UTF-8 consistently. The explanation I got from the author of Path.toUri ([2] p.c.) is that file:///some/path as produced by Path.toUri is expected to retain the original octet sequence used to construct the pathname, whereas file:/some/path may lack this information. The issue might affect interactions with forked processes. I do not understand this very well (on Linux you never have to worry about this kind of nonsense) but it may make sense to you.
[1] http://hg.netbeans.org/main/file/release72_base/openide.util/src/org/openide/util/Utilities.java#l3025 [2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7176702 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
