RFR 8224068: [lworld] JCK api/java_lang/invoke/MethodHandles/Lookup/ExceptionsTests crashes
mandy.chung at oracle.com
Fri May 31 16:45:25 UTC 2019
Ok. For now, `Lookup::findStatic` will allow to accept the static
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.
More information about the valhalla-dev