[code-reflection] RFR: BytecodeGenerator support of lambdas [v7]

[Paul Sandoz]

On Tue, 16 Apr 2024 14:29:11 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> `InnerClassLambdaMetafactory` generates the hidden inner class (for example: `lambda_0x00007ff000189400$$Lambda/0x00007ff000117a08`) and then it all fails with:
>> 
>> java.lang.ClassNotFoundException: lambda.0x00007ff000189400
>> 	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
>> 	at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
>> 	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:525)
>> 	at TestBytecode.consume(TestBytecode.java:291)
>> 	at java.base/java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:733)
>> 	at TestBytecode.lambda$testGenerate$14(TestBytecode.java:476)
>> 	at TestBytecode.permutateAllArgs(TestBytecode.java:412)
>> 	at TestBytecode.testGenerate(TestBytecode.java:475)
>
> I've identified `j/l/i/defineHiddenClass/BasicTest::testLambda` is actually not testing a lambda in a hidden class, but rather a MH in a hidden class.
> If I modify `j/l/i/defineHiddenClass/src/Lambda` from `Function<Object, String> f = Object::toString;` to `Function<Object, String> f = o -> o.toString();` the test fails with:
> 
> java.lang.NoClassDefFoundError: Lambda/0x00007ff00029e800
> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:641)
> 	at java.base/java.util.ArrayList.forEach(ArrayList.java:1597)
> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:641)
> 	at java.base/java.lang.Thread.run(Thread.java:1575)
> Caused by: java.lang.ClassNotFoundException: Lambda.0x00007ff00029e800
> 	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
> 	at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
> 	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:525)

That seems like a bug to me, although i can understand why it might not seem like that too :-)

-------------

PR Review Comment: https://git.openjdk.org/babylon/pull/48#discussion_r1567679126