Better integration between ABCL & Java
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
On 2015/8/25 18:48, Blake McBride wrote: […]
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.
[…] Any chance of showing your code? Given a method name and arguments, [JSS already has code that figures out what method to call][1], so I'm not quite sure what you are missing. [1]: http://abcl.org/trac/browser/trunk/abcl/contrib/jss/invoke.lisp#L166 -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
It would be great if a solution could be found. I will put my code up on github soon. Thanks. Blake On Tue, Aug 25, 2015 at 12:01 PM, Mark Evenson <evenson@panix.com> wrote:
On 2015/8/25 18:48, Blake McBride wrote:
[…]
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.
[…]
Any chance of showing your code?
Given a method name and arguments, [JSS already has code that figures out what method to call][1], so I'm not quite sure what you are missing.
[1]: http://abcl.org/trac/browser/trunk/abcl/contrib/jss/invoke.lisp#L166
-- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
Blake, if you're creating CLOS classes just to have method dispatch - you're not required to do it. ABCL's generic functions can dispatch on Java classes, e.g. (defmethod foo ((arg (jclass "java.util.List"))) ...). Of course they respect Java's class hierarchy. As for overloaded methods... you could merge them in a single method and let ABCL decide. (defmethod foo ((x (jclass ...)) &rest args) (apply #'jcall x args)) I see another, perhaps bigger problem, the mismatch between Java and Lisp namespaces. If Java classes A and B have a method called m, will it be mapped to the same Lisp generic function named (by the symbol) M? If so, you need to know beforehand the entire Java class hierarchy in order to coalesce same-named methods, not just in a single class but across unrelated classes. I.e. mapping won't be incremental unless you do extra bookkeeping to make it so. On the other hand, if you map A.m and B.m to package-a:m and package-b:m, then you don't need CLOS at all, you manually dispatch using the package system. -- Stepping in the general discussion, I don't want to be inflammatory, but... I'm not contributing to the project any more, and it's been quite a long time since I did, but I wouldn't say ABCL is unfit for enterprise and poorly integrated with Java. Actually I think it has a strong Java integration, even if some pieces, namely class generation, are incomplete (BTW, ABCL *can* generate annotated Java classes *today*). OSGi is a strange beast, never used it much, but IIRC a few years ago I had trouble using Java libraries with OSGi because it places restrictions on how JARs are structured... many libraries are repackaged just for OSGi, and I don't know how other languages, Groovy, JRuby etc. fare with OSGi. So I think it is unfair to blame ABCL here. And no, Java 9 won't force OSGi on everyone's code - Java 9 just adds support for modularity (not OSGi) in the VM (not in user code). Even if the system classloader is changing and that could have an impact on ABCL (did anyone try it on OpenJDK 9?). As for ant vs Maven, I don't like ant personally, but if a build system is in place and it's stable and it works... why replace it? Maven is well fit for standard Java projects, but ABCL's build is more complex than most of those, and I'm not sure Maven, or even Gradle, would be more fit than ant in this case. Also because ABCL has no third-party dependencies I see little incentive to migrate to a Maven based build. Just my humble .02 Alessio On Tue, Aug 25, 2015 at 8:00 PM, Blake McBride <blake@mcbride.name> wrote:
It would be great if a solution could be found. I will put my code up on github soon.
Thanks.
Blake
On Tue, Aug 25, 2015 at 12:01 PM, Mark Evenson <evenson@panix.com> wrote:
On 2015/8/25 18:48, Blake McBride wrote:
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.
[…]
Any chance of showing your code?
Given a method name and arguments, [JSS already has code that figures out what method to call][1], so I'm not quite sure what you are missing.
[1]: http://abcl.org/trac/browser/trunk/abcl/contrib/jss/invoke.lisp#L166
-- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
A few years ago my organization built a large application using SBCL. The customer then decided he wanted to integrate that into a Java display system. At first the team anticipated many months of work integrating SBCL and Java. I then pointed out ABCL. As I recall the complete integration took less than two months. This includes the time required to spool up a few Java programmers into lisp. Sometime later (after I left the project) the customer decided to rewrite everything in Java. Our lisp crew was reassigned. Later I heard that they were having a very difficult time. I never heard that it was completed.
On Aug 30, 2015, at 05:28 , Alessio Stalla <alessiostalla@gmail.com> wrote:
Blake,
if you're creating CLOS classes just to have method dispatch - you're not required to do it. ABCL's generic functions can dispatch on Java classes, e.g. (defmethod foo ((arg (jclass "java.util.List"))) ...). Of course they respect Java's class hierarchy.
As for overloaded methods... you could merge them in a single method and let ABCL decide. (defmethod foo ((x (jclass ...)) &rest args) (apply #'jcall x args))
I see another, perhaps bigger problem, the mismatch between Java and Lisp namespaces. If Java classes A and B have a method called m, will it be mapped to the same Lisp generic function named (by the symbol) M? If so, you need to know beforehand the entire Java class hierarchy in order to coalesce same-named methods, not just in a single class but across unrelated classes. I.e. mapping won't be incremental unless you do extra bookkeeping to make it so. On the other hand, if you map A.m and B.m to package-a:m and package-b:m, then you don't need CLOS at all, you manually dispatch using the package system.
--
Stepping in the general discussion, I don't want to be inflammatory, but... I'm not contributing to the project any more, and it's been quite a long time since I did, but I wouldn't say ABCL is unfit for enterprise and poorly integrated with Java. Actually I think it has a strong Java integration, even if some pieces, namely class generation, are incomplete (BTW, ABCL *can* generate annotated Java classes *today*). OSGi is a strange beast, never used it much, but IIRC a few years ago I had trouble using Java libraries with OSGi because it places restrictions on how JARs are structured... many libraries are repackaged just for OSGi, and I don't know how other languages, Groovy, JRuby etc. fare with OSGi. So I think it is unfair to blame ABCL here. And no, Java 9 won't force OSGi on everyone's code - Java 9 just adds support for modularity (not OSGi) in the VM (not in user code). Even if the system classloader is changing and that could have an impact on ABCL (did anyone try it on OpenJDK 9?). As for ant vs Maven, I don't like ant personally, but if a build system is in place and it's stable and it works... why replace it? Maven is well fit for standard Java projects, but ABCL's build is more complex than most of those, and I'm not sure Maven, or even Gradle, would be more fit than ant in this case. Also because ABCL has no third-party dependencies I see little incentive to migrate to a Maven based build.
Just my humble .02 Alessio
On Tue, Aug 25, 2015 at 8:00 PM, Blake McBride <blake@mcbride.name <mailto:blake@mcbride.name>> wrote: It would be great if a solution could be found. I will put my code up on github soon.
Thanks.
Blake
On Tue, Aug 25, 2015 at 12:01 PM, Mark Evenson <evenson@panix.com <mailto:evenson@panix.com>> wrote:
On 2015/8/25 18:48, Blake McBride wrote:
[…]
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.
[…]
Any chance of showing your code?
Given a method name and arguments, [JSS already has code that figures out what method to call][1], so I'm not quite sure what you are missing.
[1]: http://abcl.org/trac/browser/trunk/abcl/contrib/jss/invoke.lisp#L166 <http://abcl.org/trac/browser/trunk/abcl/contrib/jss/invoke.lisp#L166>
-- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
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/e4b9e7d261e8e5d2a9ce38cc464c... 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
participants (5)
-
Alessio Stalla -
Blake McBride -
Mark Evenson -
Peter Olsen -
Ralph Ritoch