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

[Per Bothner <per@bothner.com>]

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/