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

[Maurizio Cimadamore]

On Fri, 28 Jun 2024 16:12:43 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Yes, it's a temporary solution We need to think more carefully about a better location such as a method attribute or synthetic annotation, but I think we should do that separately, and we also need to consider quotable lambda expressions too.
>
> Honestly, I would go for a simple fix which addresses this annoying problem now, and perhaps discuss on other ways to address this issue in a separate PR? Specifically, adding attributes etc. seems like throwaway work, given that we might have other plans for how these things should be serialized in the classfile?

> Could we encode an instance of `MethodRef` in the field name like we do with the invoke operation's descriptor? (I believe there are less restrictions in the names of synthetic fields than ones that can be denoted in source.) That might be easier to manage on the compile time and run time sides.

Are you asking if, instead of serializing the signature, we couldn't just (a) obtain the `MethodRef` object corresponding to the reflectable method and (b) add that to the synthetic field name? Seems possible, and probably provides a better way to pick that one up reflectively.

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

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