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@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