CL and Java - Part 4
Sunday, July 11, 2004
Rich Hickey has
announced the availability of jfli (pronounced "jay fly") on the
LispWorks mailing list and the comp.lang.lisp newsgroup. I mentioned
his project in an
earlier posting and also commented on a POC that
Jeff Caldwell was doing along the same lines.
I downloaded jfli and tried it out and am quite impressed. Here is
what it can do (from
Rich Hickey's docs):
" My objective was to provide comprehensive, safe, dynamic and Lisp-y access to Java and Java libraries as if they were Lisp libraries, for use in Lisp programs, i.e. with an emphasis on working in Lisp rather than in Java.I tried the included demos and they worked fine. The SWT example was particularly interesting (although all it does is display a simple Java SWT dialog box with a button which, when pressed, calls back to LispWorks to get the version number of LispWorks). What interested me was the potential for using jfli together with SWT to develop native look-and-feel UI's.
The approach I took was to embed a JVM instance in the Lisp process using JNI. I was able to do this using LispWorks' own FLI and no C (or Java! *) code, which is a tribute to the LW FLI. On top of the JNI layer (essentially a wrapper around the entire JNI API), I built this user-level API using Java Reflection. This first version was built with, and contains code specific to, Xanalys LispWorks.
jfli ("jay fly") provides:I built jfli using LWM and LWW (using Apple's and Sun's JVMs respectively), and it works fine on both. Should be a trivial port to other LispWorks, and a possible port to any Common Lisp with a robust FLI. Should also work with any JVM with a conformant JNI implementation."
- Automatic function generation for constructors, fields and methods, either by named class, or entire package (sub)trees given a jar file.
- Java -> Lisp package and name mapping with an eye towards lack of surprise, lack of conflict, and useful editor completion.
- setf-able setter generation for fields as well as for methods that follow the JavaBeans property protocol.
- Java array creation and aref-like access to Java arrays.
- A 'new' macro that allows for keyword-style field and property initialization.
- Typed references to Java objects with an inheritance hierarchy on the Lisp side mirroring that on the Java side - allowing for Lisp methods specialized on Java class and interface types.
- Implementation of arbitrary Java interfaces in Lisp, and callbacks from Java to Lisp via those interfaces. (* this required a single 5-line dummy Java proxy stub, provided with jfli)
- Automatic lifetime maintenance of Lisp-referenced Java objects, boxing/unboxing of primitive args/returns, string conversions, Java exception handling, overload resolution etc.
The lack of a cross-platform, cross-implementation rich-client UI for CL has been lamented many times in the past. Java's answers to this same problem have all fallen short until the recent introduction of SWT. Java's AWT framework used native widgets but adopted a "Least Common Denominator" (LCD) approach. Although it provided consistency, people didn't like the loss of functionality that AWT's LCD approach dictated. The next attempt was the Swing framework which attempted to address the LCD problem by providing a rich set of common non-native widgets. While AWT failed because of the LCD approach, Swing failed because of the lack of native widgets (which made Swing apps look, ummm, non-native). SWT is a new UI framework (originally introduced by IBM as part of the Eclipse project) and provides native widgets without the LCD limitations. The result is a UI framework that has a native look-and-feel and is also cross-platform.
Now, admitedly, jfli is not really cross-implementation (it only runs on LispWorks at the moment, although Rich reckons that it wouldn't be difficult to port jfli to any CL with a good FLI implementation) nor is it's support of SWT cross-platform (it runs on Win32 but has some problems running on Mac OS X and hasn't been tested on Linux); however, it is just a beta release and these issues will probably be resolved in later revs of the library. So, the potential for using SWT as a common UI framework for CL rich client applications looks very promising. In fact, SWT may prove to be the "killer app" for jfli.
