I've managed to go pretty far down the road to implementing "jar:" references "correctly" into ABCL so some closing notes for the night:
Alan Ruttenberg noted in private communication that [the javadoc for java.net.URLConnection][1] has a pretty decent "specification" of what I am trying to do, with the caveat that I am only implementing the "jar:" for URIs in the "file:" schema. This suggests that we should look to making PATHNAME more generic in supporting schemas like "http:". This would all presumably thunk down to the support in java.net.URL, and only be practically used for the "file" and "http" schemas. We might have a problem with pathnames in that their namestrings could never start with "file:" or "http:", but maybe we would be willing to sacrifice strict CL compatibility here for a more natural fit. After all, we currently have that for files that are called "jar:file:baz.jar!/foo". My hunch is that there will be always be corner-cases in the pathname back and forth to namestring interface that will always exist which is inherent in the ANSI CL specification in that in leaves the actual semantics of DEVICE, HOST, etc. up to implementations.
[1]: http://java.sun.com/javase/6/docs/api/java/net/JarURLConnection.html
The documentation for JarURLConnection indicates that a URI that references the JAR itself must always end in "!/" like
jar:file:baz.jar!/
This makes my previous insistence that (pathname-device #p"jar:file:baz.jar!/foo") return "baz" instead of "jar:file:baz.jar" a little less necessary, so I will revisit this decision, especially in light of the need for recursive jar file references.
The recursive entries arrise if I am going to implement the TRUENAME stuff correctly (which will make the current LOAD code a lot less hairy). Consider a JAR archive called "baz.jar". It contains an ABCL packed FASL known as "bar.abcl" (i.e. "bar.abcl" is itself a JAR containing "bar._", "bar-1.cls", "bar-2.cls", etc.). To reference the first FASL stored in "jar:file:bar.abcl!/bar-1.cls", I propose use the seeming monstrosity:
jar:jar:file:baz.jar!/bar.abcl!/bar-1.cls
Seems to logically check out in my head, but if others spot an error please chime in.
And the current implementation fails with
load("jar:file:baz.jar!/bar")
anyways as this is the part that started failing with the recent AutoloadedFunctionProxy implementation.