[armedbear-devel] Lisp / Java interface utilities and examples

[Alessio Stalla]

On Tue, Feb 2, 2010 at 6:14 PM, Ville Voutilainen
<ville.voutilainen at gmail.com> wrote:
> 2010/1/30 Blake McBride <blake at mcbride.name>:
>> Greetings,
>> Enclosed are the completed Lisp and Java utilities designed to make Lisp /
>> Java interaction easier.  It also includes an example / tutorial program.
>> If it is appropriate, I'd like to have these added as one of the ABCL
>> examples in the distribution.  Also, if it is advantageous, perhaps we can
>> move the Lisp and Java utilities to be part of ABCL.
>
> Looks good. I think the ABCL java class could benefit from a setter for the
> interpreter, and a getter, so that you could use it as a decorator. Wherever
> an instance of Interpreter is created, I think it's better to allow
> people to use
> that instance for other things Interpreter is capable of. I'd add the
> possibility
> to have per-ABCL-instance Interpreters, as well as the option of having a
> class instance.
>
> The utils.lisp stuff looks like it could well be added to our
> java.lisp, probably
> slightly tweaking the function names to follow the normal java.lisp conventions.
>
> Would you like to do such tweaks, or should I? :)
>
> Alessio, this is your familiar playground, any comments on these utils?

The Java utils for what I can see are a subset of what is already
there in AbclScriptEngine, with the difference that - iirc - the
script engine automatically calls javaInstance() on the returned
objects, so you don't have the possibility to access "raw" Lisp
objects (e.g. calling a function that returns a Fixnum will return an
Integer instead).

The lisp utils could be handy, but I'd prefer to call jmethod, jclass
and similar during macroexpansion and including the results in the
expanded code; this way no method/class reflective lookup will be done
at runtime. For maximum safety, it would be even better to fall back
to calling jmethod in the expansion, and warn, if method resolution
fails at compile time.

Wrt. multiple Interpreter instances, it's not entirely true that you
can only have one; you can use two different, unrelated classloaders
to load two copies of ABCL. It's true that, in that case, interacting
with them with code from yet another classloader (say, a manager
thread), will be harder and slower, as you can only use reflection;
but if you just want two or more independent ABCLs, that can be the
way to go.

hth,
Alessio