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

[Roger Riggs]

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
>