Le 22 août 2012 à 00:04, Jesse Glick a écrit : > 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.
It seems to me that FileUtils.getFileURL is doing the job correctly. I have then deprecated Locator.fileToURL and replace it by FileUtils.getFileURL > 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. Don't understand the encoding issue there, since we are manipulating Strings. Since FileUtils.getFileURL is generating a String with only ASCII characters, it seems safe. > [1] > http://hg.netbeans.org/main/file/release72_base/openide.util/src/org/openide/util/Utilities.java#l3025 For the UNC files, something seems off, probably because I just discovered what UNC paths are. :) As far I understand, such path reference some file on a remote computer. But then why the host part of the URI being build is left to null ? > [2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7176702 It seems we cannot become "watchers" of jvm bugs, can we ? Nicolas --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
