jfli-abcl, basically, allows one to quickly create Lisp function wrappers for Java classes.
E.g.
(def-java-class "java.sql.DriverManager") (use-package :|java.sql|) (DriverManager.getConnection ...)
The benefit over java:jcall and JSS is that it looks more-or-less like normal Lisp function calls, pretty similar to a wrapper you could write yourself. Also, potentially, it might carry less runtime overhead because everything can be resolved at compile-time.
And if you use SLIME, auto-completion works. It doesn't like mixed case, though, so you need to write it like (|java.sql|:drivermanager.getcollection ...) Still, better than nothing.
As far as I can tell, jfli-abcl isn't currently maintained. But as I'm used to jfli-abcl I maintain my own version with some fixes.
If there is any interest in jfli-abcl I could, perhaps,. publish my version and polish it a bit.
(I'm personally not interested in new-class functionality which allows one to create Java class from Lisp.)
(I've found this updated version: https://gist.github.com/avodonosov/abcl-idea/blob/master/src/abclidea/lisp/j... But haven't yet checked if it works with latest ABCL and what are improvements against old one.)
On 5/23/12 3:06 PM, Alex Mizrahi wrote: […]
As far as I can tell, jfli-abcl isn't currently maintained. But as I'm used to jfli-abcl I maintain my own version with some fixes.
If there is any interest in jfli-abcl I could, perhaps,. publish my version and polish it a bit.
(I'm personally not interested in new-class functionality which allows one to create Java class from Lisp.)
(I've found this updated version: https://gist.github.com/avodonosov/abcl-idea/blob/master/src/abclidea/lisp/j...
If jfli-abcl is pure Common Lisp, I offer to package it as a ABCL-CONTRIB extension. JSS is only one of the experiments in Java syntax we would like to support in our aim to make the Bear polymorphously perverse.
All one needs to do is create a toplevel ASDF definition in 'jfli.asd' and move it into 'ABCL_ROOT/contrib/jfli/' in the build tree.
After recompiling, the source may be loaded into the running JVM via the CL:REQUIRE mechanism:
(require :abcl-contrib) (require :jfli)
Right now I'm really trying to triage stuff for [abcl-1.1.0][], but if you gave me a patch to apply to [ABCL trunk][2], I could easily commit it.
[abcl-1.1.0]: http://trac.common-lisp.net/armedbear/milestone/1.1.0 [2]: http://code.google.com/p/abcl-dynamic-install/source/browse/
Hi Alex,
I also have my own hacked up version of jfli, if you want to have a look it is here:
https://github.com/mrohne/jfli
Ole
On 2012-05-23, at 15:06 , Alex Mizrahi wrote:
jfli-abcl, basically, allows one to quickly create Lisp function wrappers for Java classes.
E.g.
(def-java-class "java.sql.DriverManager") (use-package :|java.sql|) (DriverManager.getConnection ...)
The benefit over java:jcall and JSS is that it looks more-or-less like normal Lisp function calls, pretty similar to a wrapper you could write yourself. Also, potentially, it might carry less runtime overhead because everything can be resolved at compile-time.
And if you use SLIME, auto-completion works. It doesn't like mixed case, though, so you need to write it like (|java.sql|:drivermanager.getcollection ...) Still, better than nothing.
As far as I can tell, jfli-abcl isn't currently maintained. But as I'm used to jfli-abcl I maintain my own version with some fixes.
If there is any interest in jfli-abcl I could, perhaps,. publish my version and polish it a bit.
(I'm personally not interested in new-class functionality which allows one to create Java class from Lisp.)
(I've found this updated version: https://gist.github.com/avodonosov/abcl-idea/blob/master/src/abclidea/lisp/j... But haven't yet checked if it works with latest ABCL and what are improvements against old one.)
armedbear-devel mailing list armedbear-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
I also have my own hacked up version of jfli, if you want to have a look it is here:
Works fine, thanks!
So I think it would be great to include it into abcl-contrib to make it clear which version is maintained and working.
But I think it's better to rename it back to jfli-abcl to avoid confusion.
Also I've noticed that Ole removed new-class functionality, which is essentially a wrapper for java:jnew-runtime-class. I don't think we need new-class either, but included examples use it, so we need to add different examples. Or we can bring new-class back.
What is the status of this ticket: http://trac.common-lisp.net/armedbear/ticket/153 If it still requires external lib then I guess we can live without it.
On 28 May 2012 13:09, Alex Mizrahi alex.mizrahi@gmail.com wrote:
Also I've noticed that Ole removed new-class functionality, which is essentially a wrapper for java:jnew-runtime-class. I don't think we need new-class either, but included examples use it, so we need to add different examples. Or we can bring new-class back. What is the status of this ticket: http://trac.common-lisp.net/armedbear/ticket/153 If it still requires external lib then I guess we can live without it.
I think removing the external dependencies from runtime-class is still not finished. It would be cool to have it, including new-class.
On Mon, May 28, 2012 at 12:09 PM, Alex Mizrahi alex.mizrahi@gmail.com wrote:
I also have my own hacked up version of jfli, if you want to have a look it is here:
Works fine, thanks!
So I think it would be great to include it into abcl-contrib to make it clear which version is maintained and working.
But I think it's better to rename it back to jfli-abcl to avoid confusion.
Also I've noticed that Ole removed new-class functionality, which is essentially a wrapper for java:jnew-runtime-class. I don't think we need new-class either, but included examples use it, so we need to add different examples. Or we can bring new-class back.
What is the status of this ticket: http://trac.common-lisp.net/armedbear/ticket/153 If it still requires external lib then I guess we can live without it.
Some time ago I restored some runtime-class functionality: enough to create a class, implement methods in Lisp, and add annotations. I didn't announce it publicly because it's still missing important features, like defining fields, constructors, call superclass methods... if anyone is interested in contributing, we can discuss the ideas I have. I intend to add what's missing eventually, but don't expect it too soon.
The API is not the same, though I used the old one as inspiration. The implementation is written in pure ABCL with no external dependencies, using Erik's great class file writer (plus an addition of mine to handle annotations).
Alessio
On 5/28/12 12:09 PM, Alex Mizrahi wrote:
I also have my own hacked up version of jfli, if you want to have a look it is here:
Works fine, thanks!
So I think it would be great to include it into abcl-contrib to make it clear which version is maintained and working.
I have [committed this version of JFLI to ABCL-CONTRIB][1] without much testing beyond ensuring that it loads via:
(require :abcl-contrib) (require :jfli)
[1]: http://trac.common-lisp.net/armedbear/changeset/13949
Contributions to ensuring that this version satisfies users needs are solicited, particular in the following points
1) If you are a casual user of JFLI, please try your code with the version we have committed to trunk, reporting success or failure to the mailing list.
2) We should figure out which parts of [Anton's extensions][2] we should include, especially wrt to the need for 'asm.jar' for creating synthetic Java classes at runtime.
[2]: https://gist.github.com/avodonosov/abcl-idea/blob/master/src/abclidea/lisp/j...
3) A basic test suite would be good. Possibly one could bootstrap this by somehow running the included examples to just verify that they load and run correctly. N.b. Please root ABCL-CONTRIB specific test suites underneath 'abcl/contrib' as opposed to 'abcl/test'.
4) A contribution to the [fine manual][3] outlining basic usage would be nice, akin to the level we describe JSS. I'll probably just cobble together a stub for the abcl-1.1.0 manual, but it would definitely need expansion who understands JFLI better than I do.
[3]: http://trac.common-lisp.net/armedbear/browser/trunk/abcl/doc/manual/abcl.tex
P.S. I chose to name the extension "jfli" as opposed to "jfli-abcl", as it should be pretty obvious to anyone running this that they are dealing with an ABCL specific version of JFLI. In adopting the name "jfli", we are certainly committing to maintaining compatibility with other Lisp implementation's use of the abstractions to the point that code that JFLI code that runs on SBCL should run on ABCL. If this is not a reasonable goal, we should of course change our name to avoid confusion.
P.P.S. I confess to needing more education of the care and feeding of JFLI so perhaps my "decisions" wrt to the commit are not the best ones, but I wanted to get something into the ABCL trunk so that we could kick the tires a bit. And hopefully we can get quickly get enough patches from JFLI from its actual users to make the version included with ABCL canonical.
29.05.2012, 11:30, "Mark Evenson" evenson@panix.com:
The changeset misses jfli.lisp, only jfii.asd.
- We should figure out which parts of [Anton's extensions][2] we
should include, especially wrt to the need for 'asm.jar' for creating synthetic Java classes at runtime.
I did only one fix (it is included in the jfli contrib, but without comment).
The change is in the function get-ref.
To explain it's meaning we should first say that jfli, when working with native java objects, wraps the java object into a lisp wrapper.
The function get-ref returns the object referenced by the lisp wrapper, i.e. the native java object (and if the argument is already a native java object, as determined by the ABCL function java:java-object-p, it returns the argument). This was the original version.
In the original form, the function get-ref signaled an error if we pass something that is not a jfli wrapper or native java object. For example (get-ref (lambda () "hello")) signaled an error.
I've added an otherwise clause so that (get-ref (lambda () "hello")) returns the lambda - in case of ABCL, object of lisp world are anyway java objects - it is possible for JVM to assign the value of (lambda () "hello") to any field of type java.lang.Object.
I needed this change because I wanted to create java class MY.MyAction extends com.intellij.openapi.actionSystem.AnAction, which holds reference to a lisp function in a field named "func" of type java.land.Object.
This allowed me to create actions for Intellij IDEA as instances of this class, and easily set different lisp functions as handlers for different actions.
This usage is here, starting at line 211, https://gist.github.com/avodonosov/abcl-idea/blob/fd017ed722bbdd66d40095a949...
In particular: (setf act-yank (myaction.new "yank" nil)) (setf (myaction.func act-yank) #'(lambda (action-event) ...))
In the second setf, when we assign the value to the myaction.func field, the jfli generated setter calls get-ref on the #(lambda (action-event) ...) argument and stores the returned value in the "func" field of the action object.
That's the explanation why I changed it. Now the question, should this change be included into ABCL version of jfli? I.e. should get-ref function just return it's argument in otherwise clause?
I think yes.(probably adding a comment to the otherwise clause will be good).
Best regards, - Anton
On 5/29/12 10:37 AM, Anton Vodonosov wrote:
29.05.2012, 11:30, "Mark Evenson"evenson@panix.com:
The changeset misses jfli.lisp, only jfii.asd.
Corrected in [r13950][]. Thanks!
r13950: http://trac.common-lisp.net/armedbear/changeset/13950
- We should figure out which parts of [Anton's extensions][2] we
should include, especially wrt to the need for 'asm.jar' for creating synthetic Java classes at runtime.
I did only one fix (it is included in the jfli contrib, but without comment).
The change is in the function get-ref.
A failing test has been [added in r13951][r13951].
r13951: http://code.google.com/p/abcl-dynamic-install/source/detail?r=68bda250259a7f...
Loading via the [ASDF definition fails for my versions of trunk like the failure I just noticed.][#213].
[#213]: http://trac.common-lisp.net/armedbear/ticket/213
I'll get to a merge of Anton's function later. Somebody elses patchset before then is always welcome…
--
"A screaming comes across the sky."
Hello
23.05.2012, 17:06, "Alex Mizrahi" alex.mizrahi@gmail.com:
(I've found this updated version: https://gist.github.com/avodonosov/abcl-idea/blob/master/src/abclidea/lisp/j... But haven't yet checked if it works with latest ABCL and what are improvements against old one.)
The changes comparing to the original version are annotated in the sources.
In my opinion new-class is important to have because creating classes is often needed when interacting with java libraries: to create a thread we need a Runnable, to handle a button click we need an ActionListener, to find files in directory we need a Filter.
If independent version of new-class is not ready, probably it's possible to deliver runtime-class a a contrib, and user if wants to load it should provide asm.jar in the classpath?
I mean to have jfli-abcl contrib which provides all the functions which possible without runtime-class/asm.jar, but when we need new-class, we can get it too by having asm.jar in classpath and loading the runtime-class contrib?
Best regards, - Anton
28.05.2012, 16:22, "Anton Vodonosov" avodonosov@yandex.ru:
If independent version of new-class is not ready, probably it's possible to deliver runtime-class a a contrib [...]
I've checked the ABCL sources and see that runtime-class.lisp is now included into ABCL. So we don't even need to create a contrib for it.
Could anyone help me understand the problem with new-class, why removing it? Namely, when the asm.jar will be needed,
What I understand now:
1. abcl-jfli function jrc calls java:jnew-runtime-class. 2. java:jnew-runtime-class needs asm.jar.
Basically, my question is when the asm.jar is needed, during load time o fabcl-jfli or only at run time, when we call the jfli:jrc?
I see
(export 'jnew-runtime-class "JAVA") (autoload 'jnew-runtime-class "runtime-class")
that runtime-class.lisp is present in autoloads.lisp, but I do not clearly understand how autoloads work, that's why I ask this question.
Anyway, if the dependency on asm.jar is a load-time dependency (in that case it's a real problem for the users who don't need new class functionality and don't want to carry asm.jar), we can solve it by changing the calls
(java:jnew-runtime-class other args)
to
(funcall (read-from-string "java:jnew-runtime-class") other args).
This will resolve compile/load time dependencies for sure.
Best regards, - Anton
On Mon, May 28, 2012 at 2:22 PM, Anton Vodonosov avodonosov@yandex.ru wrote:
Hello
23.05.2012, 17:06, "Alex Mizrahi" alex.mizrahi@gmail.com:
(I've found this updated version: https://gist.github.com/avodonosov/abcl-idea/blob/master/src/abclidea/lisp/j... But haven't yet checked if it works with latest ABCL and what are improvements against old one.)
The changes comparing to the original version are annotated in the sources.
In my opinion new-class is important to have because creating classes is often needed when interacting with java libraries: to create a thread we need a Runnable, to handle a button click we need an ActionListener, to find files in directory we need a Filter.
Note that in many cases (Runnable, ActionListener, etc.) you're actually implementing interfaces, not classes. That functionality is already in ABCL (jmake-proxy) and has been since a long time, because it is directly supported by the Java Reflection API.
Extending concrete classes *is* useful or even necessary in certain scenarios, but you can do a surprising amount of work with just interfaces, assuming the libraries you're dealing with are written in good style. And runtime-class is usable right now in a lot of cases; at the last European Lisp Symposium, I showed a proof of concept work where I replaced Groovy with Lisp in my employer's flagship product, to write custom action classes with the Stripes framework: to do that, I used present-day runtime-class. The most important missing feature is the ability to call superclass methods, and that's something I'm working on these days; constructors are only useful generally if the superclass mandates them, and fields are rarely necessary because method implementations can be closures.
If independent version of new-class is not ready, probably it's possible to deliver runtime-class a a contrib, and user if wants to load it should provide asm.jar in the classpath?
I mean to have jfli-abcl contrib which provides all the functions which possible without runtime-class/asm.jar, but when we need new-class, we can get it too by having asm.jar in classpath and loading the runtime-class contrib?
That would be possible, but I object that having 2 different APIs for the same thing is a potential source for confusion.
Peace, Alessio
armedbear-devel@common-lisp.net
-
Alessio Stalla -
Alex Mizrahi -
Anton Vodonosov -
Mark Evenson -
Ole Myren Rohne -
Ville Voutilainen