To incite some discussion about what steps are required to make it convenient to write Java from within CL. The result should probably be added to Trac.
Short term:
* make Java objects inspectable.
* make DESCRIBE be useful on Java objects. Should mention inheritance tree, public attributes, and methods.
* fix inconsistencies, for example JMETHOD takes class-name first, then method-name, but JSTATIC takes it the other way around.
Medium term:
* make JMethods be a subclass of FUNCALLABLE-INSTANCE, so they can be funcalled, passed to HOFs, stored into SYMBOL-FUNCTION etc.
* add reader-macros for convenience. For example, #J'class.method for (jmethod "class" "method").
* add iteration macro, HOFs, for Java Collections.
* Figure out how to get arglist information from Java methods.
* Documentation
* Useful PRINT-OBJECT methods for Java Objects. For example, Collection objects could be printed showing their content, e.g. #<JAVA-CLASS COLLECTION [a b c d e]>. Make sure to make it heed the printer variables properly, though.
Long term:
* Add an extensible sequence protocol, and make Java Collection abide it.
* integrate Java's object hierarchy into the CLOS object hierarchy. I'm not a CLOS expert, but a few people come to mind who to ask.
* Make it possible to extend Java classes from Lisp.
* Make it possible to implement Java interfaces from Lisp.
People who have experience with Clojure, and other Lisp-like languages on the JVM are welcomed to chime in how other do the integration, and how they like it.
Also people who have opinions how they'd like it to look like.
-T.
I will put a word in for my package jss, which I have used for quite a bit of development (e.g. the inspector I mentioned in a previous email, as well as LSW, also mentioned).
Jss calls are all dynamic dispatch, and explicit imports are not necessary. Classpath can be dynamically added to.
Here is an example of code that uses jss.
(defun make-swing-window-for-panel (name panel) (let* ((w (new 'javax.swing.JFrame name)) (content-pane (#"getContentPane" w))) (#"add" content-pane panel) (#"pack" w) w))
Source code is at: http://svn.mumble.net:8080/svn/lsw/trunk/jss/
Regards, Alan
On Fri, Jul 31, 2009 at 6:18 PM, Tobias C. Rittweilertcr@freebits.de wrote:
To incite some discussion about what steps are required to make it convenient to write Java from within CL. The result should probably be added to Trac.
Short term:
* make Java objects inspectable.
* make DESCRIBE be useful on Java objects. Should mention inheritance tree, public attributes, and methods.
* fix inconsistencies, for example JMETHOD takes class-name first, then method-name, but JSTATIC takes it the other way around.
Medium term:
* make JMethods be a subclass of FUNCALLABLE-INSTANCE, so they can be funcalled, passed to HOFs, stored into SYMBOL-FUNCTION etc.
* add reader-macros for convenience. For example, #J'class.method for (jmethod "class" "method").
* add iteration macro, HOFs, for Java Collections.
* Figure out how to get arglist information from Java methods.
* Documentation
* Useful PRINT-OBJECT methods for Java Objects. For example, Collection objects could be printed showing their content, e.g. #<JAVA-CLASS COLLECTION [a b c d e]>. Make sure to make it heed the printer variables properly, though.
Long term:
* Add an extensible sequence protocol, and make Java Collection abide it.
* integrate Java's object hierarchy into the CLOS object hierarchy. I'm not a CLOS expert, but a few people come to mind who to ask.
* Make it possible to extend Java classes from Lisp.
* Make it possible to implement Java interfaces from Lisp.
People who have experience with Clojure, and other Lisp-like languages on the JVM are welcomed to chime in how other do the integration, and how they like it.
Also people who have opinions how they'd like it to look like.
-T.
armedbear-devel mailing list armedbear-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
On Sat, Aug 1, 2009 at 12:18 AM, Tobias C. Rittweilertcr@freebits.de wrote:
To incite some discussion about what steps are required to make it convenient to write Java from within CL. The result should probably be added to Trac.
Short term:
* make Java objects inspectable.
Working on that ;)
* make DESCRIBE be useful on Java objects. Should mention inheritance tree, public attributes, and methods.
* fix inconsistencies, for example JMETHOD takes class-name first, then method-name, but JSTATIC takes it the other way around.
Medium term:
* make JMethods be a subclass of FUNCALLABLE-INSTANCE, so they can be funcalled, passed to HOFs, stored into SYMBOL-FUNCTION etc.
Cool. I never thought about this, it's a great idea. We probably need a JMethod extends JavaObject class to make this easier.
* add reader-macros for convenience. For example, #J'class.method for (jmethod "class" "method").
This would be useful, but I also think we should provide some kind of alias system to avoid having to write the full Java class name every time.
I have some private code that allows me to do (jimport "java.lang.String" 'string) and later use 'string as a Java class designator with a bunch of ad-hoc functions. E.g. (new 'string "asfdsf"). However, it's built on my personal taste, which does not make it automatically suited for being the user-level interface between Lisp and Java.
Also having to provide the full list of argument types to select a method is tedious: we need the possibility to choose the method at runtime based on the number and type of arguments, while of course retaining jmethod for lower level stuff, as it's more optimized. Again, I have code for this, and there's invoke.lisp too, and probably other solutions floating out there.
* add iteration macro, HOFs, for Java Collections.
* Figure out how to get arglist information from Java methods.
* Documentation
* Useful PRINT-OBJECT methods for Java Objects. For example, Collection objects could be printed showing their content, e.g. #<JAVA-CLASS COLLECTION [a b c d e]>. Make sure to make it heed the printer variables properly, though.
Yeah, that's very important imho. #<JAVA-OBJECT java.lang.Long {12345}> looks much worse than e.g. #<jlong 42>. We could maybe also use the #J macro above, or another reader macro, to make at least java primitive types and Strings readable.
Long term:
* Add an extensible sequence protocol, and make Java Collection abide it.
I'm for it all the way.
* integrate Java's object hierarchy into the CLOS object hierarchy. I'm not a CLOS expert, but a few people come to mind who to ask.
I did something along the lines of this some months ago (it should already be in abcl, but it hasn't been publicized - and tested - much). Basically, calling CLASS-OF on java objects returns a CLOS metaclass which describes the Java class hierarchy, and it is possible to have CLOS methods dispatch following that hierarchy, using the nonstandard (jclass "class") method specializer. This is very incomplete - general CLOS does not work on these metaclasses (e.g. no make-instance to create new objects, no introspection, etc.) but can be a starting point.
- Make it possible to extend Java classes from Lisp.
what about runtime-class?
- Make it possible to implement Java interfaces from Lisp.
This is already possible, although it probably needs a higher-level api (i.e. one or more macros allowing one to implement interfaces declaratively).
People who have experience with Clojure, and other Lisp-like languages on the JVM are welcomed to chime in how other do the integration, and how they like it.
Also people who have opinions how they'd like it to look like.
-T.
armedbear-devel mailing list armedbear-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
Hello,
on Saturday, August 1, 2009, 1:18:53 AM Tobias wrote:
Long term: [...] * Make it possible to extend Java classes from Lisp. * Make it possible to implement Java interfaces from Lisp.
It is possible already, with JAVA:JNEW-RUNTIME-CLASS, although maybe the form isn't really convenient.
To have JAVA:JNEW-RUNTIME-CLASS in ABCL it is necessary to compile org/armedbear/lisp/runtime-class.lisp. It requires asm.jar [1] to be in classpath, and therefore, as far as I understand, is excluded from compilation by default (see <exclude name="org/armedbear/lisp/runtime-class.lisp"/> in build.xml).
Another interesting source that may be useful to define convenient java interop is port of Rich Hickey's Jfli [2] to ABCL. I found the ABCL version created by asimon@math.bme.hu here: http://www.math.bme.hu/~asimon/lisp/jfli-abcl.tar.
jfli-abcl provides a macro (experimental) NEW-CLASS macro for creation java classes in Lisp (including inheritance from existing classes/interfaces). NEW-CLASS is a wrapper around JAVA:JNEW-RUNTIME-CLASS. Some examples of it's usage are also provided.
I'd say NEW-CLASS macro isn't perfect from usability point of view, but may probably be used as a starting point for something better.
- integrate Java's object hierarchy into the CLOS object hierarchy. I'm not a CLOS expert, but a few people come to mind who to ask.
Jfli approaches this problem: http://jfli.sourceforge.net/#wrappergen
I am using these tools now to create a plugin for for Intellij IDEA (nothing serious, more like a hello world). Maybe I'll post it as an example to the list soon.
In the attach is the jfli-abcl.lisp I use. It fixes small error in the NEW-CLASS (one backqoute :). And adds a kind of extension/fix: constructors for NEW-CLASS created classes may accept not only jfli wrapped java objects, but also native Lisp objects (which are java objects anyway in case of ABCL).
1. ASM java bytecode manipulation framework home is here: http://asm.ow2.org/ ABCL seems to use not the latest one, but elder 1.5.3 version: http://forge.ow2.org/project/download.php?group_id=23&file_id=3084
2. http://jfli.sourceforge.net/
Best regards, - Anton
armedbear-devel@common-lisp.net
-
Alan Ruttenberg -
Alessio Stalla -
Anton Vodonosov -
Tobias C. Rittweiler