RFR 8224068: [lworld] JCK api/java_lang/invoke/MethodHandles/Lookup/ExceptionsTests crashes
mandy.chung at oracle.com
Fri May 31 00:58:47 UTC 2019
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