As a result of the failure I just fixed in r13105, I tried to understand more broadly about our interaction with the URL/URI/File Java universe.
What I found:
* We're constantly converting URL->URI->file-based pathname * When converting an absolute URI to a file object using the File(URI uri) constructor for file: URIs, the process strips the leading slash that preceeds the windows drive letter * We can't "just" convert paths to URIs by doing ["file:" + path], because that's not a valid URI. However, it seems that we should be able to do [new URI("file", null, path, null, null);] as it seems that the URI does its own encoding, *if* we use the multi-argument constructors. Any single-string should be pre-encoded. * We seem to be required to support relative URIs in a non-standard way (like "jar:file:baz.jar"); the standards do allow relative path URIs, but those are requred to be without a schema.
All of the above has me thinking:
1. Should we separate the different types of supported pathnames into separate Java classes, with a single entry point (factory?) 2. Would it make sense to separate internal representation from external presentation? Hopefully, this way we can circumvent the fact that the URI<->File conversion really wants absolute paths, while the external presentation is relative. 3. It seems that any URL/URI->path conversion should go through the normalization routines defined by the File(URI uri) constructor, because it seems to do the right thing with URI's - even on Windows.
Comments?
Regards,
Erik.