Better integration between ABCL & Java

[Alessio Stalla]

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> 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> 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."
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/armedbear-devel/attachments/20150830/e195d5cd/attachment.html>