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

[Frederico Muñoz]

Greetings,

Thank you for your answer!

Alessio Stalla <alessiostalla at gmail.com> writes:
> This is great, thank you very much for taking the time to write these examples!

My pleasure, I'm glad you found them worthwhile. I was also surprised to
see this post in Planet Lisp via Zach Beane's blog, which was cool :)

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

I didn't even considered anything related to performance. For my
purposes in terms of simple GUI programming I would not mind trading
some performance for overall ease of use though... well, depending on
the real difference in terms of user experience of course.

Having said that, it would be interesting to benchmark the different
APIs.

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

Since it's Rich Hickey's work before Clojure it is interesting to
compare, and since ABCL recently incorportated it I was intrigued by 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
> (...)

That's not entirely unlike what JFLI does: I'm using (use-package
"javax.swing") since JFLI maps Java packages to CL packages; what you
are proposing is the mapping of Java *classes* to CL packages, which I
agree would reduce the "clutter" somewhat, especially because it is IMO
a bit strange to have to specificy the class of a method *and* provide
the object that receives it.

JFLI seems to go to great lenghts to integrate itself into CL packages,
etc. I'm still exploring it though. JSS OTOH "just works", it's simple
to use and does what it is supposed to (JFLI requires a bit more setup).

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

Didn't knew about java:chain, thank you - I'm still reading about the
java interop facilities, my impression is that there is a lot under the
hood that isn't known (and thus not used). I'm still going to add the
"low level" example that uses jcall, jmethod, etc.


>> 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")
>> (...)
> Yep. Personally I don't like it very much, because it's more stuff
> than a simple reader macro...

True. I think that the ability to simple use (settext my-label "The
Larch") would be great, but I suspect that if this was simple it would
already be done ;)

A bit OT, but not unlike another obvious idea, which would be to support
CLIM using Java interop and Swing, thus making code targeted at ABCL
universal in both ways: completely self-contained due to the JVM, and
also able to be deployed in other CL implementations. This would IMO be
something that would make the "CL hosted on the JVM" really shine.

This assumes that CLIM is actually 1) a standard and 2) a good approach
to GUI programming, something that can be debated

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


Thank you, I will do that. As I mentioned preivously perhaps my
(completely trivial) experimentation can help in uncovering hidden
functionality with examples, etc.  The CLOS specialisation seems
extremely interesting BTW.

"Write Java classes in Lisp"... this is, I must confess, where I am
stuck at the moment. I'm trying to make another, slightly more complex,
example that involves a canvas-like interface. For this the examples I
find (in Java) imply overriding the paintComponent method of
JPanel. This is something that apparently can't be made by using
interfaces, I need a new class (or proxy). I can't seem to find how to
do this in ABCL - at least using JSS or JFLI. This is such a deal
breaker that I am surely missing something obvious.

BTW, I've read some of your material in Snow, I haven't gone for that
route yet since before using a framework I want to understand the gory
details, but it's very helpful.

Thank you and best regards,

Frederico