[code-reflection] RFR: Lump constructor reference with method reference

[Paul Sandoz]

On Wed, 12 Nov 2025 15:29:11 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Perhaps, the right thing to do would be to always use `MH::lookup`-like resolution semantics (for both `MethodRef` and `FieldRef`, and regardless of what the resolution output is a reflective class or not).

Agreed. The use cases in HAT and ONNX and in the test `TestTransitiveInvokeModule` are intended to work with method refs that are use site descriptors (or where the receiver/owner is not always the declaring class) e.g., when building a call graph. 

I am not sure why we added the declared variants, perhaps i was getting confused trying to support method resolution and method handle resolution in a consistent way. We need the former to trampoline from a method declaration to its code model, if present, when building a call graph of reflected methods.

We should be able to compose method resolution from method handle resolution, and for method resolution maybe it is possible to avoid passing in the invoke kind if we first try method handle resolution to a instance method and then try to a static method?

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

PR Comment: https://git.openjdk.org/babylon/pull/677#issuecomment-3523220109