RFR 8224068: [lworld] JCK api/java_lang/invoke/MethodHandles/Lookup/ExceptionsTests crashes

[Mandy Chung]

On 5/20/19 10:08 AM, John Rose wrote:
> Correct.  Reasons:  static <init> methods correspond to source-level
> constructors.  jlr has a choice to classify them as jlr.Methods or
> jlr.Constructors.  It should not put them both places, since they
> are not in two places in the source code.  It is less surprising
> to classify them according to their source form than to the
> bytecode-level form chosen by the translation strategy.

Classifying the static <init> factory as a `Constructor` rather than 
`Method` makes sense to me.

> Reminder:  jli is different from jlr because it reflects only
> bytecode behavior, not source code.  jli reflects both,
> with some irregularity, but tilts towards source code.
> For example, it reflects inner classes as members.

Lookup::findConstructor is for the bytecode pattern new+dup+invokespecial.

To lookup the static <init> factory, we could make `Lookup::findStatic` 
to allow finding the static <init> factories.  "Constructor" in jlr but 
a static method in jli might easily cause confusion.

Would it worth introducing a new `Lookup::findStaticConstructor` instead 
(bytecode pattern invokestatic)?  I think the method name makes it 
clearly distinct from an object constructor and other static methods and 
unreflectConstructor and findConstructor/findStaticConstructor return 
MethodHandle of an object/static constructor.   CONSTANT_MethodHandle 
continues to use the same reference-kind option.

Mandy