>Yes, that helps a lot.  Thanks.  Is there some specific documentation
>about this in a user manual or guide?  What have I missed?  I grabbed

I suppose this is just the way ABCL + JVM works in contrast to how the Java language
runtime works with the JVM. The JVM is language-agnostic, at least in theory. The JVM
and its bytecode are probably heavily Java-oriented as Java was for a very long time
the only language that used the JVM bytecode as an intermediate representation.
The constructs that Java uses are still just things build on top of the JVM bytecode -
ABCL uses different constructs (built also on top of JVM bytecode), because
it's not trivially straightforward to represent lisp types as java objects, or vice versa. Even
though the underlying bytecode is the same (same as in adheres to the same
bytecode standard, or an instruction set if you will), the type/object models of
different languages built on top of the bytecode might be vastly different.

The ABCL Interpreter provides the mapping from lisp types to Java objects. Of course
it would probably be possible to include this mapping directly in the JVM bytecode generated
by ABCL, but that would probably also be overkill for uses where the lisp-generated bytecode
is only used by other ABCL byte code. There's also the problem that it's likely hard
to find a Java-object-representation of lisp code that suits all purposes, I suppose
utilizing the ABCL Interpreter as an intermediate mapper is a more generic approach
and thus more flexible, even though it means that a simple use case of "let's invoke functions
defined in lisp from java" is not as easy as using java functions from java. :)

Same "impedance mismatch" can be seen when you invoke Java code from ABCL,
or invoke Java code from C/C++ through JNI - Java is heavily object-oriented, it has
no "free" functions (non-methods), so languages that *do* have "free" functions
need to use a translation layer (in this case JNI) to invoke methods on java objects.
The invocations are possible through the translation layer, but they are never
as straightforward as invoking functions without a translation layer. The thing is,
if there is no translation layer, the type/object models of the invoked code and the
invoking code must match. To oversimplify, the matching object model is visible,
sort of, by having an identical syntax on both sides (although syntax doesn't really
mandate a type/object model). You can have a forced object model match (that
would be having the ABCL generated byte code contain actual Java objects),
but that would likely restrict the capability of the system to the lowest common
denominator. As an example, if the ABCL byte code contained Java objects,
how would you ever be able to invoke lisp macros?