On Sun, 30 Oct 2005 at 11:58:55 -0500, Rich Hickey wrote:
> Well, nothing has been 'abandoned', but being one person with a
> limited amount of spare time (none currently) I have to focus my
> effort. None of my projects has seen significant interest or input,
> and I would characterize the number of people in the CL community who
> care about Java integration as very small - perhaps they are all
> working on/with ABCL :)
> Nevertheless, I am still actively engaged in how best to integrate
> Lisp and the JVM/CLR and intend to continue to contribute to this
> area when I have time.
> Re: Clojure - I have reached the point where I am planning support
> for defining Java/CLR classes etc and have realized that this is
> something I should have implemented first. While I only have a small
> amount of Java runtime lib code, if Clojure itself were capable of
> generating decent Java classes and calls, ideally I should have none
> (bootstrap issues aside). I am always surprised at the inordinate
> amount of Java code in Lisp-in-Java implementations and I think this
> is because they, too, added this later in the game. Otherwise, why
> write so much Java? - the whole reason we do these things is so at
> the end of the day we won't have to.
The bootstrap issues can be formidable.
My experience has been that it has proved very useful during ABCL's
development to have its core written in pure Java, even though it's a
bit annoying to have to deal with such a large body of Java code.
> I am also questioning whether or not I can get the level of
> integration that I desire, and that is expected by the not-already-CL-
> users community, and remain CL compatible. I've only attempted a very
> small subset of CL in Clojure, but still encounter thorny issues esp.
> as relates to unifying the type systems. The conversions and wrappers
> of jFli are convenient and fun, and as long as you are using
> reflection the performance overhead is a non-issue, but when you are
> compiling it's a different story.
> Some of the things I am contending with in Clojure are:
> Should aref work on Java arrays?
> When calling a Java function that returns a string, do you get a Lisp
> string or a Java string?
> Should the non-mutating string library functions be made to work on
> Java strings?
> Should the generic function system be able to dispatch on Java types
> (i.e. not wrappers)?
> Can (some of) the sequence functions be made to work on Java
> How does conditional logic handle Java null? Java booleans?
> The fact is that CL has 'closed-over' much of its type system and is
> not really extensible in many areas. Which leaves all CL-compatible
> approaches having to deal with Java via an FFI such as jFli or
> jLinker, and thus a lot of jthis and jthat, conversions, wrappers
> etc. I had hoped to avoid much of that in Clojure, but I'm not sure I
> can and remain a proper CL subset that supports interactive
> development via Foil. So, I'm thinking, thus the quiescence.
> I am not interested in re-inventing wheels, and with its license
> change, I am happy to see ABCL dominate the CL-in-Java space. I would
> be very excited to see it adopt some Java calling primitives it would
> guarantee would compile into efficient direct Java calls, as well as
> compile-time Java class definition syntax (at which point I might
> become a serious user). I think ABCL is stunning in it's level of CL
> conformance, and is the logical home for the (hopefully compilable)
> future of jFli.
I can certainly see reasons why one would want to call Java code from
Lisp (the obvious one being to be able to use library code that would
otherwise not be available), but not being much of a Java programmer, I
have a harder time imagining why one would want to write a non-trivial
Java class in Lisp when Lisp code can be compiled to efficient JVM
Of course you'd want to be able to implement an interface and be able
to do callbacks and handle events, but it seems like these things can
be done with relatively simple wrappers. Maybe I'm wrong about that.
(And I'm probably ignoring some large class of applications that have
totally different requirements.)
In any event, my bias made a lot of decisions easy. ABCL is a full
Common Lisp and uses the CL type system, for better or worse; the Java
type system is not visible to Lisp. A LispObject is not identical to a
java.lang.Object. Strings are mutable. The Lisp side sees only
LispObjects, never a Java null or a Java boolean or a Java array or a
One of the design goals is that a user seeing just the repl should not
even be aware that ABCL is implemented in Java.
I've just started to look at the issue of having ABCL's compiler
generate efficient direct Java calls, using the JCALL/JMETHOD stuff. I
still don't think it's much of a problem, but I have no proof of that
On the other hand, it's clear that there will always be at least a
little overhead when you cross the Lisp/Java boundary, in either
direction. That doesn't bother me; I don't cross it much.
In the event that I actually need to define a real Java class, I'll
probably just do it in Java.
That shouldn't be taken to mean that ABCL won't ever provide some way
of defining a real Java class. I do want to get rid of the ASM
dependency in JNEW-RUNTIME-CLASS and friends, and a class definition
syntax (is it really a syntax?) may fall out of that work.