[armedbear-devel] Integration of CL and Java

[Alessio Stalla]

On Sat, Aug 1, 2009 at 12:18 AM, Tobias C. Rittweiler<tcr at 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 at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
>