public inbox for kawa@sourceware.org
 help / color / mirror / Atom feed
From: Phil Eaton <phil@eatonphil.com>
To: Per Bothner <per@bothner.com>
Cc: spellcard199 <spellcard199@protonmail.com>,
	kawa mailing list <kawa@sourceware.org>
Subject: Re: Receiver class does not define or inherit an implementation of the resolved method
Date: Tue, 7 Sep 2021 15:45:56 -0400	[thread overview]
Message-ID: <CAByiw+opaCbWSaPGe_cST4j7H9N+ZKff7Qj_Ht3Dp5rw18EHeg@mail.gmail.com> (raw)
In-Reply-To: <7042c6a7-b4a4-e2a8-f67a-cd420ef1f90c@bothner.com>

>  Also note that it does not generate $X suffixes - but suffixes of the
form $nn where nn is an integer.

Sorry I was unclear. From my javap dump in a previous message the problem
was about methods called `apply` and `apply$1`. When I said $X I meant
where X is some integer.

I did do a bunch of grepping but it hadn't turned up yet. Since
that gnu/expr/LambdaExp.java code is adding a literal $X I don't think
that's what I'm looking for.

On Tue, Sep 7, 2021 at 3:31 PM Per Bothner <per@bothner.com> wrote:

> On 9/7/21 6:02 AM, Phil Eaton wrote:
> > Separately, I was messing around in Kawa trying to understand where this
> $X suffix is generated on duplicate methods. I did find fixParamNames in
> gnu/bytecode/Scope.java:110. It has a note saying that $X suffix was
> required because of _Android_/dex. I commented this method out and
> recompiled and ran my example but it still generated the $X suffix. So I
> guess that's not the place where the method name is generated for bytecode
> compilation.
>
>  From what I can tell/remember. fixParamNames has nothing to do with
> method names.
> It avoids duplicates in *variable* names, which apparently dex
> complains/complained about.
> (These local variable names are only used for debugging.)  Also note that
> it does not
> generate $X suffixes - but suffixes of the form $nn where nn is an integer.
>
> If you're on a Unix-like system with a shell that understands **,
> then the following is a useful trick:
>
>      grep '"[$]X"' **/*.java
>
> That takes you gnu/expr/LambdaExp.java, where "$X" is added  when the
> method
> takes an extra CallContext parameter (which is related to the tail-call
> support).
>
> When it comes to having multiiple methods with the same name, same
> parameter types,
> but different return types that is allowed by the JVM but not by the Java
> source language.  However, Java 5 introduced "covariant return types":
> Consider class T extends class S, and class S has a method f() return S.
> It is often useful for class T to override f such that it returns a T.
> (Or more generally an overriding method returns a subtype of the method it
> overrides.)  To implement this, javac will generate two methods: one that
> returns a T, and additionally an artifical "bridge method" that calls the
> former but whose return type is S.
>
> If I recall correctly, Kawa doesn't support covariant return types,
> though it would be a nice feature to add.  That might be the problem
> you're having, but I'm not sure.
> --
>         --Per Bothner
> per@bothner.com   http://per.bothner.com/
>

  reply	other threads:[~2021-09-07 19:46 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-29 19:03 Phil Eaton
2021-08-30 16:40 ` Per Bothner
2021-08-30 23:09   ` Phil Eaton
2021-08-30 23:18     ` Phil Eaton
2021-09-07 10:59       ` spellcard199
2021-09-07 13:02         ` Phil Eaton
2021-09-07 17:58           ` spellcard199
2021-09-07 19:35             ` Phil Eaton
2021-09-08 14:14               ` spellcard199
2021-09-08 14:20                 ` spellcard199
2021-09-07 19:31           ` Per Bothner
2021-09-07 19:45             ` Phil Eaton [this message]
2021-09-07 20:13               ` Per Bothner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAByiw+opaCbWSaPGe_cST4j7H9N+ZKff7Qj_Ht3Dp5rw18EHeg@mail.gmail.com \
    --to=phil@eatonphil.com \
    --cc=kawa@sourceware.org \
    --cc=per@bothner.com \
    --cc=spellcard199@protonmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).