RFR 8224068: [lworld] JCK api/java_lang/invoke/MethodHandles/Lookup/ExceptionsTests crashes
john.r.rose at oracle.com
Fri May 31 16:16:34 UTC 2019
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
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