[armedbear-devel] Pathname.java, or: trying to understand the Java URL/URI/File universe

[Erik Huelsmann]

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.