Better integration between ABCL & Java

[Ralph Ritoch]

Blake,

My plan for calling lisp from java, and for supporting OSGI, is to separate
the interface from the implementation. Changing all functions to accept
interface arguments and return interface types.  When it comes to calling
Java methods from lisp, and dealing with properly matching the correct java
method I believe the issue would be more easily handled with macro's and
caching of reflection objects which probably belongs as an extension
library. The apply function is one of the more difficult problems to solve
when it comes to interfacing between java and lisp. I faced this issue with
Clojure and did eventually find a solution by using eval.

https://github.com/rritoch/clj-grid-kernel/blob/e4b9e7d261e8e5d2a9ce38cc464c6d6fbea414d8/src/com/vnetpublishing/clj/grid/lib/grid/kernel.clj#L99-L110

Best Regards,
  Ralph Ritoch

On Wed, Aug 26, 2015 at 12:48 AM, Blake McBride <blake at mcbride.name> wrote:

> Greetings,
>
> I worked hard on a project to link ABCL with a very large Java
> application.  Although the addition of ABCL to that project failed, the
> work I did could be of use, and with some effort could be made to solve the
> problem I had.  I believe the original problem I had would be a very common
> problem in similar circumstances.
>
> My pre-existing Java application has almost 10,000 classes!  I wasn't
> about to create lisp cover functions for each java method.  I also wasn't
> going to use a convoluted syntax to get to java each time.
>
> What I did was create some Java and Lisp code that, through reflection,
> caused the system to auto-generate a complete set of CLOS classes to mirror
> my primary java application classes - including the class hierarchy.  The
> methods in these CLOS classes would call the Java methods.  With this, when
> in Lisp, I could just use all of my Java classes and methods as regular
> CLOS classes and methods.  It's use of Java classes and methods internally
> was transparent to lisp.  All of this worked fine.
>
> The problem I ran into was the fact that Java can have several methods
> with the same name but different arguments.  So, the Java method being
> called depended on the types and number of arguments too (not just the
> class of the instance and the method name).  I never solved this, although
> I think it could be.  I just ran out of time and steam, as well as other
> non-technical reasons.
>
> The reason I bring this all up now is because I am unclear about what
> problems Ralph is trying to solve.  I thought what I have done may be of
> use.
>
> Thanks.
>
> Blake McBride
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/armedbear-devel/attachments/20150826/115b1146/attachment.html>