RFR 8224068: [lworld] JCK api/java_lang/invoke/MethodHandles/Lookup/ExceptionsTests crashes
john.r.rose at oracle.com
Fri May 17 21:52:29 UTC 2019
On May 17, 2019, at 11:12 AM, Harold Seigel <harold.seigel at oracle.com> wrote:
> The simplest fix for this seemed to be to just throw NoSuchMethodError in findConstructor() if the constructor has a non-void return type.
This is correct. This is a key difference in the treatment of
constructors between java.lang.reflect and java.lang.invoke.
The type java.lang.reflect.Constructor merges both kinds of
<init> functions under one heading, because jlr is (partly)
about language-level concepts.
The method findConstructor only looks for API points that
have the bytecode use pattern of new+dup+invokespecial.
This is because jli is about *bytecode behaviors* not about
reflecting *source code constructs*.
We'll have a small bug tail with this, but if the above principles
are kept in mind we should straighten it out quickly.
This should answer Roger's question. Karen, when I said
"do both" I probably meant the above. At least, that's where
I came to after I worked out the coding details. So neither
jli or jlr reflects these things both ways.
The jlr package has a strong assumption that constructors
(per se, at the bytecode level) use the new+dup+invokespecial
pattern. Let's not try to shoehorn the new <init> factory
methods into that small space; the new+dup+invokespecial
thingy is magic enough and risky enough without packing
it next to other kinds of invocation modes.
So, Harold, your first fix is correct. Trust your *feelings*
More information about the valhalla-dev