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

[Mandy Chung]

Ok.  For now, `Lookup::findStatic` will allow to accept the static 
<init> factories.

Mandy

On 5/31/19 9:16 AM, John Rose wrote:
> I would be OK with having a new API point for Lookup,
> just for the new static init factories.  But I don't like the
> term "static constructor", though, because that seems to
> say something about the language and/or bytecode
> specification.  I don't think this layer of the API should
> coin such a term, because it would cause other kinds
> of confusion up and down the related parts of the stack.
>
> We need to consult with one of our JVMS experts (Dan)
> to find out what will be the bytecode-level name of
> this kind of bytecode method.  I have been calling it
> "static init factory" as a place-holder.
>
> For now let's keep it "buried" as a regular method,
> in the Lookup API, until and unless we get a canonical
> term from the JVMS.
>
> Roger, about the new/dup/invoke dance, you are right
> that it would be a plausible move to replace it with a
> more regular static factory API, at the bytecode level.
> (Exception:  This won't work for sub- to super-class
> <init> calls, but those are special anyway.)  And if we
> did that then we could unify the term "constructor"
> around those hypothetical canonical static factory
> methods, all of which would be (probably) static
> init factories.  I'd like to do this "some day", but it
> will be an expensive cleanup.  For now, I think
> today's Lookup API can't anticipate that usefully;
> it always does better to reflect the JVMS as directly
> as possible.
>
> — John
>
> On May 30, 2019, at 5:58 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
>>
>>
>> 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