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

[Roger Riggs]

Hi John,

I thought I understood until the last paragraph was attributed to 
java.lang.reflection:
  "the jlr package has a strong assumption ... new+dup+invokespecial".
It seems to contradict "jli is about *bytecode behaviors*" and 
"j.l.r.Constructor merges both kinds of <init> functions".

Please confirm:

- For java.lang.reflect, all <init> constructors and static <init> 
methods will be exposed as constructors.
- static <init> methods returning the type will not be exposed as methods.

BTW, where is the spec for the inline static <init> methods?

Thanks, Roger


On 05/17/2019 05: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
>