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

[Alan Ruttenberg]

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

Hello.

>> 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).

I concur. I try to stay away from cl packages as much as possible.

>
> 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)

jss auto registers anything on your classpath. It will also accept
unique suffixes. So without doing anything you can say

(new 'net.uri "http://example.com/")

note new vs. jnew

> 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.

See above. However there is no search order - either it's unambiguous
or an exception is thrown and you have to be more specific.

-> (#"baz" (new 'foo))

>> 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.

Jss is case indifferent for class names if you give them as a symbol,
but respects case for strings. It will complain if you ask for
something where there is a collision. I don't do the same for method
names.
Alessio, I don't see how you get  O(2^length(classname)). It's just an
equalp hash table.

> 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.

Here's to that. I'd like to retire jss at some point.

-Alan