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

Harold Seigel harold.seigel at oracle.com
Mon May 20 14:03:46 UTC 2019


 >> So, Harold, your first fix is correct. Trust your *feelings* Luke!

Thanks ObiWan!

Harold

On 5/17/2019 5:52 PM, John Rose wrote:
> 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
>


More information about the valhalla-dev mailing list