[armedbear-devel] What is the consensus on JFLI and JSS?

[Alessio Stalla]

On Thu, Sep 23, 2010 at 10:00 PM, mahmud <bigthingist at gmail.com> wrote:
> Hi there,
>
> First, a big thank you and congratulation on a job well done, everyone!
>
> Secondly. What is the community take on jfli[1] and jss[1]? I like them
> both, and I plan to use them heavily to Lispify a few Java libraries.
> However, the two are incompatible, they both have features I would like
> to see merged.

I don't know anyone here using jfli. Instead, I know a few people
using jss, and Alan Ruttenberg, its author, posts here.

> Have there been any attempts at wrapping the native FFI with something
> higher level? I am interested in something that does the following:

Yes, I contributed some patches to make the native FFI usable with
less verbosity (but more runtime overhead) if one so wants. It's more
or less a subset of what jss already did before, but without the more
advanced features (reader macros, caching of method metaobjects,
probably other stuff I don't remember). If there's interest, I can
port other features - in any case, API compatibility with jss is a
goal for me.

> 1) Automatic importing of java packages and making them into Lisp packages.

I don't like this. Java packages aren't a well-defined entity at
runtime: you can't portably enumerate their contents, and the set of
classes in a package can vary with time (new classes get loaded) and
with classloader (the set of directly accessible classes is determined
by the current classloader).

What I would like is:

a) importing a single class name as a Lisp symbol, say (jimport-class
"com.foo.whatever" 'foo:whatever), then you can do e.g. (jnew
'foo:whatever 1 2 3)

b) using an "import list" to resolve class names against (like javac
does at compile time):
(jimport-package "com.foo")
(jimport-package "com.bar")
(jcall "baz" (jnew "Foo"))
and "Foo" is searched in com.foo and com.bar if not found.

> 2) Succinct, case-indifferent syntax.

I don't like case-indifferent either. First it means you can have
collisions, second that resolving a class is O(2^length(classname)) in
the worst case.

> I would like to extend either of them to do:
>
> 3) Subclassing of java classes in Lisp.

this will be possible, thanks to the great work of Erik Huelsmann on a
generic class file writer API. I'd like to work on it actually, but
I'm too short of time these days :(

> 4) Ability to implement java interfaces in Lisp classes.

This is already possible to a certain degree, see jmake-proxy. But you
have to translate yourself between Java method names and Lisp generic
function names, unless all your GFs are in the same package and they
are named along the Java method names (someMethodName becomes
SOME-METHOD-NAME). And of course, in any case only GFs that take the
receiver (this) object as their first parameter work without wrappers.

> I have a few more ideas, most of which are feasible, but would like to
> get the community's input on FFI wrappers before I head off in a
> solitary direction.

My own personal opinion: our FFI should be enhanced without the use of
external wrapper libraries when possible. This requires of course that
those "enhancements" are widely agreed upon by the community, that
they don't require external dependencies, and that they don't make the
low-level API perform worse.

Cheers,
Alessio