There is a little more to the explanation of how ABCL loads its FASLs that should be included for completeness, namely the use of the so-called init-fasl Lisp code. For every compilation unit ("packed FASL") there is a section of Lisp code that is read in by the Java implementation of LOAD that contains forms like:
(SYSTEM:INIT-FASL :VERSION 32) (SETQ SYSTEM:*SOURCE* #P"/Users/evenson/work/abcl/dir.lisp") (SYSTEM:%IN-PACKAGE "CL-USER") (DEFPARAMETER *TEST-PATHNAME* *LOAD-TRUENAME*) (SYSTEM:FSET 'RUN (SYSTEM:LOAD-COMPILED-FUNCTION "dir-1.cls") 71 'NIL NIL) (SYSTEM:FSET 'RUN-2 (SYSTEM:LOAD-COMPILED-FUNCTION "dir-2.cls") 485 'NIL NIL)
Special variables–like *TEST-PATHNAME* here–are declared, the proper IN-PACKAGE forms are emitted, and then forms at the end issues the loadCompiledFunction() calls to load all of the top-level compilands created by compiling "dir.lisp" which are then FSET to the proper functions. It is classes like "dir-1.cls" that may contain further static initializers
Any new load mechanism consisting purely of Java code would have to do the equivalent Java side presumably in a static initializer of some kind. The current implementation rather simplifies what sort of Java classes can exist, namely that they can only represent functions. I suppose the static initializer might be able to feed a string containing these forms to EVAL.
Alessio's musings here are interesting, but I think there is a simpler solution to the problem of removing the need for intermediate temporary files on the filesystem by changing the behavior of loadCompiledFunction() to look for some sort of special variable (like *LOAD-TRUENAME*?) to figure out where to look for the bytes to turn a into a class that can be loaded by the JVM. By "simpler solution" I mean something that can be worked out without drastic impact on the current codebase.