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

[John Rose]

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*
Luke!

— John