[code-reflection] RFR: Conflicting code reflection fields for method overrides [v2]

[Maurizio Cimadamore]

On Fri, 28 Jun 2024 16:25:33 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>>> Seems possible, and probably provides a better way to pick that one up reflectively.
>> 
>> Note that we might still have mismatches between the "source" signature of the method and the "classfile" one because of synthetic parameters. But maybe we can get there when we get there.
>
> Yes, it was more in the spirit of a quicker fix with less mangling code.

> > Could we encode an instance of `MethodRef` in the field name...
> 
> Maybe I don't know all the javac tricks, but I understand the `MethodRef` instance is composed a bit later in the process. Here we try to reconstruct the composition of it (or at least the method parameters).

I think @PaulSandoz is referring to the code model's `MethodRef` class. You can easily build one in `ReflectMethods` by calling this: `symbolToErasedMethodRef(sym)` where `sym` is the symbol of the reflectable method.

I believe the "bet" is that the `toString` representation of code model's `MethodRef` is good enough to disambiguate and, at the same time, provides an easy way for the reflective code to reconstruct and pick that back up.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/162#discussion_r1659012904