Attached find patches to ABCL trunk to fix the problems with JAR files. Additionally I have included my notes on the design which deviates a little from my original posting of a couple weeks ago. The main change from that design is that the PATHNAME DEVICE is now possiblly a proper list of jars so that

#p"jar:jar:file:foo.jar!/bar.abcl!/bar._"

constructs a Pathname that has the layout

Pathname: { device: ( Pathname { name: "foo"; type: "jar"}; Pathname { name: "bar"; type: "abcl"}; ); name: "bar"; type: "_"; }

This patch implements support for specifying ABCL FASLs from JAR files to the [documented level for JarURLConnection][1] for the LOAD, TRUENAME, and PROBE-FILE commands.

so CL-USER> (load #p"jar:file:invoke.jar!/a/b/invoke")

will search invoke.jar for an entry for "a/b/invoke.abcl", "a/b/invoke._", and "a/b/invoke.lisp", loading the first one that it finds. Actually it tries to compare timestamps, but I don't think that works so well with JAR entries.

This patch needs to be tested under Windows when I get a chance where I expect there to be easily fixed errors around the use of the "!/" separator in the pathname namestring syntax.

Loading JARs from URLs should need minor debugging to get working.

Internally this patch reworks most of the loading routines to use Pathnames instead of strings, and reduceing a lot of the complexity in looking for the correct file.

There are both Java based and Lisp based tests included. The Lisp based tests only run under UNIX, as I use a shell script to construct the JAR for testing.

[1]: http://java.sun.com/javase/6/docs/api/java/net/JarURLConnection.html

---

About the only disadvantage for the current patch is that I had to remove the use of ZipCache for entries as I was developing as it didn't make much sense. I haven't really noticed too much of a time difference for loading or compiling ABCL.

Comments? Once I get things tested under Windows, and play around with the loading from http support, I intend to commit to trunk.