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

Roger Riggs Roger.Riggs at oracle.com
Fri May 17 18:26:41 UTC 2019

Hi Harold,

How does this fix fit with 8223349 [lworld] Reflection support on static 
<init> factory methods for inline types. 

Are we not headed toward identifing the static <init> methods for inline 
types as 'constructors'?


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

More information about the valhalla-dev mailing list