Attached is a revised patch for loading ABCL FASLs from jar files.
Now loading unpacked and packed FASLs work, so it is considerably easier to package things.
To use the packed FASL variant:
0) For 'bar.lisp' containing
(defun foo () (format t ("Foo here!"))
1) Compile normally with COMPILE-FILE
CL-USER(1): (compile-file "bar.lisp")
2) Package the resulting packed FASL ('*.abcl') with JAR (or zip):
cmd$ jar cfv baz.jar bar.abcl
You can add as many packed FASLs to the jar archive as you want.
To load issue
CL-USER(1): (load "jar:file:baz.jar!/bar")
and voila!
CL-USER(2): (foo) Foo here! NIL
Note that you can't currently specify "bar.abcl" explicitly in the load form (a bug).
The code needs some refactoring love, and much further testing, but I wanted to show some progress to get feedback. Other than both Load.load() and Lisp.loadCompiledFunction() getting seriously hard to understand, there is a conceptual problem with expressing "the sub-entry of a zipped entry of a zip file" with Lisp pathnames that if someone could suggest a way around, it would clear things up. ABCL uses the trick that if a pathname has a device component and the device is actually a pathname, then the entire pathname represents a entry in a zip file with device refering to the enclosing zip file, with the enclosing pathname directory, name, and type components identifying which entry within the zip file. If we could figure out a way to specify the sub-entry of an entry it would help out the abstraction. Does it make sense to use the device component recursively something like:
pathname--+-->device["jar:file:baz.jar"]-->device["jar:file:bar.abcl"] | +-->name["bar-1.cls"]
I think that helps, but it's late, so I'll check back later to see if this still makes sense.
Mark