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

[Karen Kinnear]

Harold,

My memory of the discussions was that John said that we wanted to return the static <init> methods both as general
members and as constructors?

thanks,
Karen

> On May 17, 2019, at 2:34 PM, Harold Seigel <harold.seigel at oracle.com> wrote:
> 
> Hi Roger,
> 
> Those are good questions...
> 
> This change to MemberName.java for 8222787 implies that the static <init> methods are not constructors:
> 
>   @@ -825,11 +831,11 @@
>          *  The declaring class may be supplied as null if this is to be a bare name and type.
>          *  The last argument is optional, a boolean which requests REF_invokeSpecial.
>          *  The resulting name will in an unresolved state.
>          */
>         public MemberName(Class<?> defClass, String name, MethodType type, byte refKind) {
>   - int initFlags = (name != null && name.equals(CONSTRUCTOR_NAME) ?
>   IS_CONSTRUCTOR : IS_METHOD);
>   + int initFlags = (name != null && name.equals(CONSTRUCTOR_NAME) &&
>   type.returnType() == void.class ? IS_CONSTRUCTOR : IS_METHOD);
>             init(defClass, name, type, flagsMods(initFlags, 0, refKind));
>             initResolved(false);
>         }
> 
> Maybe this can be a topic for the next Wednesday meeting.
> 
> Harold
> 
> On 5/17/2019 2:26 PM, Roger Riggs wrote:
>> Hi Harold,
>> 
>> How does this fix fit with 8223349 [lworld] Reflection support on static <init> factory methods for inline types. <https://bugs.openjdk.java.net/browse/JDK-8223349>
>> 
>> Are we not headed toward identifing the static <init> methods for inline types as 'constructors'?
>> 
>> Roger
>> 
>> 
>> On 05/17/2019 02:12 PM, Harold Seigel wrote:
>>> Hi,
>>> 
>>> Please review the following small fix:
>>> 
>>> Open Webrev: http://cr.openjdk.java.net/~hseigel/lworld_8224068/webrev/index.html
>>> 
>>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8224068
>>> 
>>> The failing test calls MethodHandles.findConstructor(), looking for a constructor with a non-null return type.  The test expects this to fail with a NoSuchMethodError exception because no such constructors exist.
>>> 
>>> Method findConstructor() calls MethodHandles.resolveOrFail() to find the method handle with ref_kind REF_newInvokeSpecial.  This creates a MemberName object.  But new code added for JDK-8222787 <https://bugs.openjdk.java.net/browse/JDK-8222787>detects that the method is named <init> and has a return type. So, it sets the MemberName flags to be IS_METHOD | REF_newInvokeSpecial. When this MemberName object is eventually passed to the JVM MethodHandles::resolve_MemberName() function, it asserts because it expects only constructors, not methods, to have ref_kind REF_newInvokeSpecial.
>>> 
>>> The simplest fix for this seemed to be to just throw NoSuchMethodError in findConstructor() if the constructor has a non-void return type.
>>> 
>>> The change was tested by running JCK lang, vm, and api/java_lang tests on Linux-x64, by running tiers 1-2 on Windows, Mac, and Linux-x64, and tiers 3-5 on Linux-x64.
>>> 
>>> Thanks, Harold
>>> 
>>