RFR 8224068: [lworld] JCK api/java_lang/invoke/MethodHandles/Lookup/ExceptionsTests crashes
harold.seigel at oracle.com
Mon May 20 14:03:46 UTC 2019
>> So, Harold, your first fix is correct. Trust your *feelings* Luke!
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*
> — John
More information about the valhalla-dev