Re: Receiver class does not define or inherit an implementation of the resolved method

[spellcard199 <spellcard199@protonmail.com>]

Hello.

> For what it's worth this kind of redefinition of the same method
worked for me in ABCL lisp. So I know it's definitely possible to
express in Java.

I know nothing about ABCL so I trust you on the fact ABCL handles
this differently from Kawa, but I don't think in Java you do it.

If I try to write the following class in plain Java...

  public class Main {
      public static void main(String[] args) {
          Main main = new Main();
          System.out.println(main.apply("x"));
      }
      public java.lang.CharSequence apply(String s) {
          return s.concat(s);
      }
      public java.lang.Object apply(String s) {
          return s.concat(s).concat(s);
      }
  }

... it gives a compile time error:

  apply(String) is already defined in 'Main'

And the same thing happens when the methods are static.

I suppose in plain Java you can't have more than one method with both
the same:
- name
- input types

I remember being confused by this the first time I saw it, but in
hindsight it makes sense: if there were 2 methods with the same name
and input types, how could Java know which one should be called when
applied to arguments?

So my question is: does ABCL really let you have both methods at the
same time or just the lastly defined one?


‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On Tuesday, August 31st, 2021 at 1:18 AM, Phil Eaton <phil@eatonphil.com> wrote:

> I spoke too soon. The issue is that I truly do need both of these methods
>
> to be called `apply` not `apply` and `apply$1`.
>
> For what it's worth this kind of redefinition of the same method worked for
>
> me in ABCL lisp. So I know it's definitely possible to express in Java.
>
> On Mon, Aug 30, 2021 at 7:09 PM Phil Eaton phil@eatonphil.com wrote:
>
> > Aha! It gave my second apply method a different suffix. By reordering
> >
> > these two methods the whole thing somehow works.
> >
> > $ javap main\$0.class
> >
> > Compiled from "main.scm"
> >
> > public class main$0 implements io.jooby.Route$Handler {
> >
> > main$frame this$0;
> >
> > public java.lang.CharSequence apply(io.jooby.Context);
> >
> > public java.lang.Object apply$1(io.jooby.Context);
> >
> > public main$0(main$frame);
> >
> > }
> >
> > It's weird but I'll take it.
> >
> > On Mon, Aug 30, 2021 at 12:40 PM Per Bothner per@bothner.com wrote:
> >
> > > On 8/29/21 12:03 PM, Phil Eaton wrote:> Still new to Kawa. I'm trying to
> > >
> > > implement an interface (
> > >
> > > > io.jooby.Route$Handler
> > > >
> > > > <
> > > >
> > > > https://github.com/jooby-project/jooby/blob/2.x/jooby/src/main/java/io/jooby/Route.java#L247
> > > >
> > > > ).
> > > >
> > > > It only has a single non-default method, apply.
> > > >
> > > > Here's what I've got
> > > >
> > > > (define (route app method path handler)
> > > >
> > > > (let ((handler (object (io.jooby.Route$Handler)
> > > >
> > > > #| This method exists just to stop Jooby from
> > > >
> > > > trying to introspect Java code that doesn't exist because this isn't
> > > >
> > > > written in Java. |#
> > > >
> > > > ((apply (ctx ::io.jooby.Context)) ::string
> > > >
> > > > #!null)
> > > >
> > > > ((apply (ctx ::io.jooby.Context))
> > > >
> > > > ::java.lang.Object
> > > >
> > > > (handler ctx)))))
> > > >
> > > > (app:route method path handler)))
> > > >
> > > > But when this gets exercised, I get:
> > > >
> > > > [worker-1-3] ERROR io.jooby.Jooby - GET /hello-world 500 Server Error
> > > >
> > > > java.lang.AbstractMethodError: Receiver class main$0 does not define or
> > > >
> > > > inherit an implementation of the resolved method 'abstract
> > > >
> > > > java.lang.Object
> > > >
> > > > apply(io.jooby.Context)' of interface io.jooby.Route$Handler.
> > >
> > > I don't see anything obviously wrong. One thing to try is instead of an
> > >
> > > anonymous class (with object) use a named class (with
> > >
> > > define-simple-class).
> > >
> > > The anonymous class is more convenient of course there is some extra
> > >
> > > "magic"
> > >
> > > (such as invisible fields) that might complicate things.
> > >
> > > > Also on a tangent, I was excited about the lambda shorthand for single
> > > >
> > > > method objects. Like I said this interface only has a single non-default
> > > >
> > > > method: apply. But I tried just calling `(app:route method handler)`
> > > >
> > > > without wrapping it in the io.jooby.Route$Handler object but it still
> > > >
> > > > failed. I guess it couldn't figure out this one method.
> > >
> > > Kawa has to be able to figure out at compile time that a specific
> > >
> > > class/interface
> > >
> > > is required before it can convert the lambda to an object. (As far as I
> > >
> > > can
> > >
> > > remember, doing this conversion at run-time isn't implemented, and would
> > >
> > > be
> > >
> > > fairly complicated.) So you may need to add some more type-specifiers.
> > >
> > > I suggest using javap to look at the generated classes, to see what is
> > >
> > > going on.
> > > ---------------------------------------------------------------------------------
> > >
> > >         --Per Bothner
> > >
> > >
> > > per@bothner.com http://per.bothner.com/