From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from aibo.runbox.com (aibo.runbox.com [91.220.196.211]) by sourceware.org (Postfix) with ESMTPS id 5175B3857010 for ; Tue, 7 Sep 2021 19:31:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5175B3857010 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=bothner.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=bothner.com Received: from [10.9.9.74] (helo=submission03.runbox) by mailtransmit02.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1mNgot-0000Fs-Bf; Tue, 07 Sep 2021 21:31:47 +0200 Received: by submission03.runbox with esmtpsa [Authenticated ID (524175)] (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) id 1mNgoc-0003yK-4b; Tue, 07 Sep 2021 21:31:30 +0200 Subject: Re: Receiver class does not define or inherit an implementation of the resolved method To: Phil Eaton , spellcard199 Cc: kawa mailing list References: From: Per Bothner Message-ID: <7042c6a7-b4a4-e2a8-f67a-cd420ef1f90c@bothner.com> Date: Tue, 7 Sep 2021 12:31:25 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.8 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: kawa@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Kawa mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2021 19:31:52 -0000 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/