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

[John Rose]

On May 20, 2019, at 9:52 AM, Roger Riggs <Roger.Riggs at oracle.com> wrote:
> 
> 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".

My bad; I thought "jli" and wrote "jlr" as you surmised.

> 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.

Correct.  Reasons:  static <init> methods correspond to source-level
constructors.  jlr has a choice to classify them as jlr.Methods or
jlr.Constructors.  It should not put them both places, since they
are not in two places in the source code.  It is less surprising
to classify them according to their source form than to the
bytecode-level form chosen by the translation strategy.

Reminder:  jli is different from jlr because it reflects only
bytecode behavior, not source code.  jli reflects both,
with some irregularity, but tilts towards source code.
For example, it reflects inner classes as members.

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

In discussion only; yet to be written.

— John