From: Rich Hickey
Subject: [ANN] jfli - a Java FLI for LispWorks
Date: 
Message-ID: <dn1Ic.7971$JW6.3562397@news4.srv.hcvlny.cv.net>
A beta of jfli, an open-source Java Foreign Language Interface for 
LispWorks, is now available:

http://jfli.sourceforge.net

From: Kenny Tilton
Subject: Re: [ANN] jfli - a Java FLI for LispWorks
Date: 
Message-ID: <tX3Ic.38349$4h7.4222951@twister.nyc.rr.com>
Wow. Mad cool logo (and pronunciation), too. Nice work.

kt

Rich Hickey wrote:
> A beta of jfli, an open-source Java Foreign Language Interface for 
> LispWorks, is now available:
> 
> http://jfli.sourceforge.net

-- 
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
From: André Thieme
Subject: Re: [ANN] jfli - a Java FLI for LispWorks
Date: 
Message-ID: <ccrmqj$2uk$1@ulric.tng.de>
Rich Hickey schrieb:

> A beta of jfli, an open-source Java Foreign Language Interface for 
> LispWorks, is now available:
> 
> http://jfli.sourceforge.net

Excellent, I will test it very soon.
I am excited ;-)
Wow Rich!


Andr�
--
From: David Steuber
Subject: Re: [ANN] jfli - a Java FLI for LispWorks
Date: 
Message-ID: <87wu1aqfxr.fsf@david-steuber.com>
André Thieme <······························@justmail.de> writes:

> Rich Hickey schrieb:
> 
> > A beta of jfli, an open-source Java Foreign Language Interface for
> > LispWorks, is now available:
> > http://jfli.sourceforge.net
> 
> Excellent, I will test it very soon.
> I am excited ;-)
> Wow Rich!

Very interesting.  I was just wondering the other day if CLisp
(because it runs everywhere) could be hooked up to the JNI interface
in some way so that Java could be used for the GUI and CLisp for the
actual heavy lifting.

I should think of some other blue skys and see if they have been
implemented.

-- 
An ideal world is left as an excercise to the reader.
   --- Paul Graham, On Lisp 8.1
From: Andras Simon
Subject: Re: [ANN] jfli - a Java FLI for LispWorks
Date: 
Message-ID: <kleknhvztp.fsf@hexagon.renyi.hu>
Rich Hickey <·······@SPPAMMrichhickey.com> writes:

> A beta of jfli, an open-source Java Foreign Language Interface for 
> LispWorks, is now available:
> 
> http://jfli.sourceforge.net

This is very, very cool stuff!

Just two comments for now.

1. I have applied all the advice given on the LW mailing list, but still, at the
point where jni-create-java-vm is called, LW dies with segmentation violation.

Has anyone been able to run it on Linux?

2. How do you plan to go about subclassing Java classes? My experience is that
in using Java libraries, the ability to create instances of Java classes and
call Java methods is not enough. Maybe there is a way around this (other than
writing those subclasses in Java) that I'm not aware of. 

I struggled with this problem in ABCL, and ended up writing a class generator,
which produces classes whose methods call Lisp functions. Here's an example
from http://wwww.math.bme.hu/~asimon/lisp/swt.cl (slightly modified):

(java:jnew-runtime-class
 "FileTreeLabelProvider" ;class name
 "org.eclipse.jface.viewers.LabelProvider" ;super
 '()                                    ;no constructors
                                        ;methods        
 `(("getText" "java.lang.String" ("java.lang.Object")
    ,#'(lambda (element this)
         (jcall-raw (jmethod "java.io.File" "getName") element))
    "public")
   ("getImage" "org.eclipse.swt.graphics.Image" ("java.lang.Object")
    ,#'(lambda (element this) 
         (if (jcall (jmethod "java.io.File" "isDirectory") element)
             (java-instance (get-1 (get-image-registry) "folder"))
           (java-instance (get-1 (get-image-registry) "file"))))
    "public"))
 '()                                    ;no fields               
)
 
(For those who actually want to run this swt demo, all the necessary
ingredients are in http://wwww.math.bme.hu/~asimon/lisp/swt-example.tar.)

This has some weak points, the most prominent of which is that the Lisp
function gets Java objects as arguments, even though I can (and do) generate
clos wrappers for interesting Java classes (much as you do with
def-java-class). That's why I have to do (jcall (jmethod "java.io.File"
"isDirectory") element) instead of (is-directory-1 element) above.

But this is just an illustration of what kind of thing I'd like to see in
jfli. 

Andras
From: Rich Hickey
Subject: Re: [ANN] jfli - a Java FLI for LispWorks
Date: 
Message-ID: <YiCIc.4872$_b.3441955@news4.srv.hcvlny.cv.net>
Andras Simon wrote:

> Has anyone been able to run it on Linux?

Yes, with the IBM JVM - see:

http://sourceforge.net/mailarchive/forum.php?thread_id=5107198&forum_id=41309

> 
> 2. How do you plan to go about subclassing Java classes? My experience is that
> in using Java libraries, the ability to create instances of Java classes and
> call Java methods is not enough. Maybe there is a way around this (other than
> writing those subclasses in Java) that I'm not aware of.


Well, a nice library, such as SWT/Eclipse, often offers interfaces. If 
that is the case, you can generate proxies in jfli which implement the 
interfaces (see below) Unfortunately many libraries are not nice and 
require subclassing of concrete classes to do the simplest things - 
aargh. This will require bytecode gen which I don't currently do.

> 
> I struggled with this problem in ABCL, and ended up writing a class generator,
> which produces classes whose methods call Lisp functions. Here's an example
> from http://wwww.math.bme.hu/~asimon/lisp/swt.cl (slightly modified):
> 
> (java:jnew-runtime-class
>  "FileTreeLabelProvider" ;class name
>  "org.eclipse.jface.viewers.LabelProvider" ;super
>  '()                                    ;no constructors
>                                         ;methods        
>  `(("getText" "java.lang.String" ("java.lang.Object")
>     ,#'(lambda (element this)
>          (jcall-raw (jmethod "java.io.File" "getName") element))
>     "public")
>    ("getImage" "org.eclipse.swt.graphics.Image" ("java.lang.Object")
>     ,#'(lambda (element this) 
>          (if (jcall (jmethod "java.io.File" "isDirectory") element)
>              (java-instance (get-1 (get-image-registry) "folder"))
>            (java-instance (get-1 (get-image-registry) "file"))))
>     "public"))
>  '()                                    ;no fields               
> )
>  

It happens there is a corresponding interface in this case,
so in jfli (untested):

(def-java-class "java.io.File")
(def-java-class "org.eclipse.jface.viewers.ILabelProvider")

(use-package "java.io")
(use-package "org.eclipse.jface.viewers")

(new-proxy
  (ilabelprovider.  ;note - must be an interface
   (gettext (element)
              (file.getname element))
   (getimage (element)
              (if (file.isdirectory element)
                    ;I don't know what get-1 does, so left as is
                    (get-1 (get-image-registry) "folder")
                   (get-1 (get-image-registry) "file")))))
From: Andras Simon
Subject: Re: [ANN] jfli - a Java FLI for LispWorks
Date: 
Message-ID: <klbrikw885.fsf@hexagon.renyi.hu>
Rich Hickey <·······@SPPAMMrichhickey.com> writes:

> Andras Simon wrote:
> 
> > Has anyone been able to run it on Linux?
> 
> Yes, with the IBM JVM - see:
> 
> http://sourceforge.net/mailarchive/forum.php?thread_id=5107198&forum_id=41309

Based on what you write there, I managed to run it with the Java SDK - see my
mail to the jfli list. Thanks for the hint!

> 
> > 
> > 2. How do you plan to go about subclassing Java classes? My experience is that
> > in using Java libraries, the ability to create instances of Java classes and
> > call Java methods is not enough. Maybe there is a way around this (other than
> > writing those subclasses in Java) that I'm not aware of.
> 
> 
> Well, a nice library, such as SWT/Eclipse, often offers interfaces. If 
> that is the case, you can generate proxies in jfli which implement the 
> interfaces (see below) Unfortunately many libraries are not nice and 

Yes, although even in those cases it is sometimes more convenient to subclass,
so as not to have to implement a zillion methods. OTOH, maybe this can be
circumvented by arranging things so that calls to unimplemented methods get
delegated to an instance of a class.

But, as you say, many libraries are not nice (e.g. SWT may be, but, as far as
I can tell, JFace isn't; and it's just too damn convenient to be ignored).

So, while I also started with proxies (following Slava Pestov's suggestion), I
finally bit the bullet and did the subclassing thing. 

> require subclassing of concrete classes to do the simplest things - 
> aargh. This will require bytecode gen which I don't currently do.

If you ever decide to do that, have a look at ASM
http://asm.objectweb.org. Using it from Lisp via your def-java-class stuff is
not that bad, the result would probably look something like 

http://cvs.sourceforge.net/viewcvs.py/*checkout*/armedbear-j/j/j/src/org/armedbear/lisp/runtime-class.lisp?content-type=text%2Fplain&rev=1.9

only better done :-)

> 
> > 
> > I struggled with this problem in ABCL, and ended up writing a class generator,
> > which produces classes whose methods call Lisp functions. Here's an example
> > from http://wwww.math.bme.hu/~asimon/lisp/swt.cl (slightly modified):
> > 
> > (java:jnew-runtime-class
> >  "FileTreeLabelProvider" ;class name
> >  "org.eclipse.jface.viewers.LabelProvider" ;super
> >  '()                                    ;no constructors
> >                                         ;methods        
> >  `(("getText" "java.lang.String" ("java.lang.Object")
> >     ,#'(lambda (element this)
> >          (jcall-raw (jmethod "java.io.File" "getName") element))
> >     "public")
> >    ("getImage" "org.eclipse.swt.graphics.Image" ("java.lang.Object")
> >     ,#'(lambda (element this) 
> >          (if (jcall (jmethod "java.io.File" "isDirectory") element)
> >              (java-instance (get-1 (get-image-registry) "folder"))
> >            (java-instance (get-1 (get-image-registry) "file"))))
> >     "public"))
> >  '()                                    ;no fields               
> > )
> >  
> 
> It happens there is a corresponding interface in this case,
> so in jfli (untested):

Yes, you're right. But I do have to subclass
org.eclipse.jface.window.ApplicationWindow, I'm afraid.

> 
> (def-java-class "java.io.File")
> (def-java-class "org.eclipse.jface.viewers.ILabelProvider")
> 
> (use-package "java.io")
> (use-package "org.eclipse.jface.viewers")
> 
> (new-proxy
>   (ilabelprovider.  ;note - must be an interface
>    (gettext (element)
>               (file.getname element))
>    (getimage (element)
>               (if (file.isdirectory element)
>                     ;I don't know what get-1 does, so left as is
>                     (get-1 (get-image-registry) "folder")
>                    (get-1 (get-image-registry) "file")))))

get-1 is the clos method that my (very poorly done) def-java-class lookalike
generates for the one-argument Java method 'get'. 

Andras
From: Rich Hickey
Subject: Re: [ANN] jfli - a Java FLI for LispWorks
Date: 
Message-ID: <pHPIc.8871$_b.5870094@news4.srv.hcvlny.cv.net>
Andras Simon wrote:


> Based on what you write there, I managed to run it with the Java SDK - see my
> mail to the jfli list. Thanks for the hint!

That's great. I saw that was with 1.5, I wonder what they changed/fixed, 
as the same technique did not work with 1.4.2. I haven't looked to see 
if there are any changes to the reflection API in 1.5, given that it has 
generics support.

> So, while I also started with proxies (following Slava Pestov's suggestion), I
> finally bit the bullet and did the subclassing thing. 

I'm sure I will add that eventually. I don't disagree about the need to 
subclass. Proxies will still be convenient and useful, because you can 
derive all of the signatures from the specified interfaces.

> If you ever decide to do that, have a look at ASM
> http://asm.objectweb.org. Using it from Lisp via your def-java-class stuff is
> not that bad, the result would probably look something like 

> 
> http://cvs.sourceforge.net/viewcvs.py/*checkout*/armedbear-j/j/j/src/org/armedbear/lisp/runtime-class.lisp?content-type=text%2Fplain&rev=1.9

Thanks, I'll check that out.
From: Edi Weitz
Subject: Re: [ANN] jfli - a Java FLI for LispWorks
Date: 
Message-ID: <87d63159zy.fsf@bird.agharta.de>
On 12 Jul 2004 20:35:14 +0200, Andras Simon <······@hexagon.renyi.hu> wrote:

> 1. I have applied all the advice given on the LW mailing list, but
> still, at the point where jni-create-java-vm is called, LW dies with
> segmentation violation.
>
> Has anyone been able to run it on Linux?

I had the same problem. Rich Hickey found out that jfli can be used if
you use the IBM JDK instead of the Sun JDK. A detailed description has
been sent to the jfli mailing list and should soon be available here:

  <http://sourceforge.net/mailarchive/forum.php?forum_id=41309>

Edi.
From: Andras Simon
Subject: Re: [ANN] jfli - a Java FLI for LispWorks
Date: 
Message-ID: <kld631vx18.fsf@hexagon.renyi.hu>
Edi Weitz <········@agharta.de> writes:

> On 12 Jul 2004 20:35:14 +0200, Andras Simon <······@hexagon.renyi.hu> wrote:
> 
> > 1. I have applied all the advice given on the LW mailing list, but
> > still, at the point where jni-create-java-vm is called, LW dies with
> > segmentation violation.
> >
> > Has anyone been able to run it on Linux?
> 
> I had the same problem. Rich Hickey found out that jfli can be used if
> you use the IBM JDK instead of the Sun JDK. A detailed description has
> been sent to the jfli mailing list and should soon be available here:
> 
>   <http://sourceforge.net/mailarchive/forum.php?forum_id=41309>
> 

I'll try this. Thanks!

Andras