[code-reflection] RFR: Super expressions [v2]

[Maurizio Cimadamore]

On Fri, 6 Sep 2024 20:59:45 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Perhaps it's an implementation detail and does not matter? I was unsure.
>> 
>> Can we presume in this case that a `MethodRef` directly refers to the method? i.e., the method is declared on the referencing class.
>>     
>> Resolving a `MethodRef` to a `MethodHandle` naturally retains the referencing type since that is where the invocation occurs. When we reveal the method handle information (crack open) and reflect as a method we potentially loose the referencing type. In this case should we expect the following to hold?
>> 
>> 
>> MethodHandle mh = ...;
>> MethodHandleInfo mhi = MethodHandles.lookup().revealDirect(mh);
>> Method m = mhireflectAs(Method.class, MethodHandles.lookup()));
>> assert mhi.getDeclaringClass() == m.getDeclaringClass();
>>  ```
>
>> Perhaps it's an implementation detail and does not matter? I was unsure.
> 
> Sorry, perhaps I was getting too ahead of myself. But it seems to me that `resolveToMember(lookup)` will pass the `InvokeClass` kind by default. This will cause (if I'm correct) a `findStatic` lookup, which might fail if the type-variable has a non-static method owner?

Ah! I missed that the code is trying `static` first and then follows up with a `virtual` lookup if that one fails. I wonder if that could lead to a situation where we resolve to the wrong method e.g. if we have something like this:


class A {
    static void m() { }
}

class B extends A {
    <X> void m() { }
}


But this seems disallowed by the overriding/hiding rules. (it's probably possible to have classfiles like that though - e.g. when generated via classfile API).

-------------

PR Review Comment: https://git.openjdk.org/babylon/pull/221#discussion_r1747716582