[jep-334] Asymmetric method types of MHD vs MH

[John Rose]

On Nov 25, 2018, at 1:34 PM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
> 
> So, maybe it's better to stick with different type accessors (for lookup and invocation type, however called) both returning some suitably typed MethodTypeDesc.

+1

This is a recurring theme in the APIs for describing CP entries:
A CP entry has a low-level structure that exactly reflects the
structure in the classfile, and a high-level structure that reflects
the (probable) intention of its user, who is implementing some
translation strategy.  (Example:  High level is String.class or
int.class, low level is a C_Class for String or C_ConDy for int.)
Different (but overlapping) API clients are interested in
different levels.  When working with simple classfile
transcription, you want to pay attention to the low-level
structure and can often ignore the intention.  When making
new CP entries out of logical intentions you want a high
level API that will choose a C_Class or C_ConDy as needed
without special request; and the inverse is also useful when
inspecting classfiles for their (probable) intentions.

In this case, the low-level C_Utf8 (method or field type)
inside the C_MH is the entity which is combined with the
the MH reference-kind to imply a high-level MethodType
for the resolved MH.  That high-level MT appears nowhere
in the low-level C_MH structure, except accidentally in
the case of a ref-kind of InvokeStatic, and even then it
is masked as a C_Utf8.  The low-level MT or FT can
be derived from the C_Utf8 inside the C_NameAndType
inside the MH reference, and that is useful for working
with the Lookup API, which (in this case) pairs well with
a low-level view of the CP API.

We might have tried to get away with a very low-level
C_MH API which *only* deals with Utf8 strings (after
all that's what's there), but that is just ugly, so we also
want a low-level API which slightly raises the Utf8 strings
to FT's (as if in a C_Class/C_ConDy) or MT's (as if a
C_MT).  That helps deal with the Lookup API, which takes
these "raw" FT/MTs that are not yet combined with the
reference-kind.

But a high-level view of the MH will sometimes just want
to ask for the invocation type of the MH.  The invocation
type is the "fully cooked" type of the resolved MH object.
This is the MH::type, not the raw Utf8, or (what is about
the same thing) the type parameter in the Lookup API.

HTH

— John