[armedbear-devel] Why does jcall use reflection?

[Ville Voutilainen]

2010/1/9 Axel Rauschmayer <axel at rauschma.de>:
> I hope this is not a stupid question, but: Why does jcall use reflection?

For various historical reasons and for certain complexity reasons, I guess.

> Doesn't ABCL compile lisp to byte code? If one could statically declare to the compiler the
>intended Java class, couldn't method invocations be compiled instead of being performed via reflection?

The question is how we handle cases where people lie the static type.
:) Java compiler makes all kinds of
static checks that we might not want to reimplement, and the java
compiler api is available only since
java 1.6. Having that compiler api would allow us to convert certain
kind of imaginary static-java-call
to java code and compile that, without reinventing wheels. We still
target 1.5 and avoid forcing people
to use 1.6. Then again, we could just as well be optimistic and
generate proper exception handling
code for cases where people misuse the static declation. It's a bit of
work to get right, I suppose, so we would
need someone to do the hard work.

> OTOH, I don't know how ABCL handles interpretation versus compilation, so that might be an issue.

Interpreter could just use reflection, whereas compiler could try and
use direct calls, with some safeguarding
as mentioned above. I don't think it's at all impossible to provide a
non-reflective way to invoke java functions,
but there's a bit of work that it requires and so far it just hasn't
been done, I guess.

Other people may have insights for this, Erik has been toying with the
idea of compiling some java calls
to non-reflective calls as far as I remember. Could be that I'm
missing some impediments, of course.