[armedbear-devel] Simpe swing examples using JSS and JFLI

[Alessio Stalla]

On Fri, Jul 20, 2012 at 4:22 PM, Frederico Muñoz <fsmunoz at gmail.com> wrote:
> Greetings,
>
> I've been playing around with ABCL for some days now, especially in
> terms of the Java interop abilities and Swing. This is because I was
> searching for a Lisp that could be easily used for cross-platform GUI
> programming and easy deployed (for the user). This narrowed it down to
> the several JVM-based Lisps (ABCL, Kawa, etc) and Clojure.
>
> While I like Clojure - and "lein uberjar" is a great facility, for
> example - I'm more confortable in CL, so I did this two small examples
> that can perhaps be useful as a way to compare ABCL's different interop
> facilities with themselves and Clojure. In a way I used this to get a
> "feel" on how things would work out and make a decision.
>
>  ABCL JSS Swing Example:   http://paste.lisp.org/display/130606
>  ABCL JFLI Swing Example:  http://paste.lisp.org/display/130605

This is great, thank you very much for taking the time to write these examples!

> I'm going to make another use using the lower-level API (jcall, etc),
> for the sake of completeness, but I think that perhaps this examples can
> be helpful to others as a small reference, using a well-known
> example. For me it was quite fun and my overall impressions thus far is
> that:
>
>  1) ABCL offers different interop facilities that taken as a whole make
> it a quite capable solution for overall Java interop, including GUI
> programming.
>
>  2) The JSS approach has the advantage of being less verbose since the
> methods need not contain the class name (which looks cleaner IMO). It is
> also simpler to setup, i.e. no need for def-java-class et. al.

I think the current incarnation of JSS is mainly a layer above jcall
etc. - BUT it can be more efficient than naive use of the native Java
FFI because it knows how to cache reflection metaobjects (e.g.
methods). I don't know the details, though.

>  3) The JFLI approach integrates well with Lisp, since it provides
> completion of methods, amongst other small things. The lack of #"foo"
> syntax is also visually appealing IMO. It can also - theoretically - be
> used by JFLI installations in other Lisps. It is more verbose though,
> since methods must be preceeded with the class (class.foomethod)

Interesting. I had looked at JFLI ages ago, before I started using
ABCL, but I don't know much about it.

But really, I think the class-name-followed-by-dot prefix is a design
smell. I think that a Java class should be mapped to a Lisp package,
and methods and fields to symbols in that package (perhaps inherited
from another package following Java inheritance). Then, you would have
the options to write

(java.lang.Comparable:compare-to x y)
(Comparable:compare-to x y) ;Assuming a package nickname
(compare-to x y) ;If you imported the symbol or used the whole package

You could also map Java access modifiers to symbol visibility:

public -> external
protected -> internal, but explicitly imported in subpackages
private, default -> internal

>  4) Clojure's approach is (naturally) conceptually quite similar to
> JFLI, in the "feel" that it provides, although the use of (.fooMethod
> instance) is similar to (#"fooMethod" instance) in terms of synxtax. The
> use of macros (like doto) significantly reduces number of words used.

ABCL could certainly benefit from more high-level macros. Right now we
only have java:chain that allows you to chain method invocations, like
some Clojure operator I don't remember (->> or something) and like
a.b(x).c(y).d(z) in Java.

>  5) I see nothing in the way of implementing similar macro mechanisms on
> top of either JSS or JFLI - but I can be simplifying things brutally
> here.
>
> In the most simple scenario syntax differences are as follows:
>
>  ABCL JSS:     (#"setText" my-label "The Larch")
>  ABCL JFLI:    (jlabel.settext my-label "The Larch")
>  Clojure:      (.setText my-label "The Larch")
>
> The Clojure approach seems quite similar to the javadot approach of
> jscheme (http://jscheme.sourceforge.net/jscheme/doc/javadot.html), as
> noted in the ABCL blog - I was unaware of that.

Yep. Personally I don't like it very much, because it's more stuff
than a simple reader macro...

> More complex approachs envolving the need for proxies contain more
> differences of course.
>
> I would greatly welcome any comments concerning style and approach: I am
> completely new to this so I am probably missing a lot. It was quite
> enjoyable though, even if there are still some rough edges here and
> there (quite understandable since for JFLI I had to used trunk). I think
> that this is an area worth exploration, easy (meaning well-integrated,
> clear syntax, small impact) interop is a huge advantage.

You might want to look at the java.lisp file. It contains a bunch of
interesting and not widely known operators. ABCL's FFI is really more
than just invocation of methods; you can, among other things:

 - implement interfaces with proxies
 - specialize CLOS generic functions on Java classes
 - use Java lists as sequences
 - write Java classes in Lisp (this is work in progress)

There are also a couple of pages in the abcl wiki that I wrote or
contributed to, but they're incomplete unfortunately.

Best,
Alessio

> Thank you for your hard work, highly appreciated.
>
> Cheers,
>
> Frederico
>
> _______________________________________________
> armedbear-devel mailing list
> armedbear-devel at common-lisp.net
> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel



-- 
Some gratuitous spam:

http://ripple-project.org Ripple, social credit system
http://villages.cc Villages.cc, Ripple-powered community economy
http://common-lisp.net/project/armedbear ABCL, Common Lisp on the JVM
http://code.google.com/p/tapulli my current open source projects
http://www.manydesigns.com/ ManyDesigns Portofino, open source
model-driven Java web application framework