[armedbear-devel] [20100128] JAR file support patches

Alessio Stalla alessiostalla at gmail.com
Thu Jan 28 14:14:48 UTC 2010

On Thu, Jan 28, 2010 at 1:30 PM, Mark Evenson <evenson at panix.com> wrote:
> A [third version of patches][1] are now available to load from JARs in ABCL.
> This version can load FASLs from JARs with a asdf:load-just-fasls-op (thanks
> Alan!) implementation (see web page for instructions).
> In general this work seems to be approaching something I would merge to
> trunk with the following outstanding issues to consider:
> 1)  There is a regression in failing logical pathname translation tests in
> ABCL.TEST.LISP having to do with improper case conversion.  Probably
> introduced with the Pathname copy constructor I introduced to get around the
> MERGE-PATHNAME implementation not treating its arguments in final (which is
> currently a bug on trunk in certain conditions as well).
> 2)  Dangling open InputStreams need to be closed

This seems the most dangerous issue. IIRC in some cases abcl has this
problem even without your patch. However, it should be just a matter
of putting some try-finally blocks in the right places.

> 3)  Possibly reestablish the use ZipCache, although I don't think its a win
> in its previous form.  Maybe something using a timer thread to invalidate?
>  Seems wrong.

Since you used JarURLConnection to access resources inside JARs, you
are already using the cache which is built in the JVM, and ZipCache
is, or should be, superfluous. This cache is not mentioned in Java's
standard API documentation, but it is a known feature of at least
Sun's JVM; see for example
<http://www.szegedi.org/articles/remotejars.html>. I expect this
feature to be present in all sane JVMs (loading classes from remote
Jars without it would be much slower).

> 4)  Test the use of URLs in JAR pathnames
> 5)  Wider testing with the ANSI test suite to make sure the Pathname
> behavior is at least as correct as the previous version.

I can only say: thanks for your work, it is going to make abcl more
deploy-friendly and that's a huge bonus.


More information about the armedbear-devel mailing list