Better integration between ABCL & Java

[Peter Olsen]

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 at 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 at mcbride.name <mailto:blake at 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 at panix.com <mailto:evenson at 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."
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/armedbear-devel/attachments/20150830/1c768c43/attachment.html>