RFR: 8343064: ClassFormatError: Illegal class name from InnerClassLambdaMetafactory [v4]

[Jorn Vernee]

On Wed, 13 Nov 2024 17:01:14 GMT, Chen Liang <liach at openjdk.org> wrote:

>> After the ClassFile API migration, when serializable lambdas are requested for hidden class callers, illegal class name is generated for the serialization methods, which previously had legal yet unusable class names, as hidden classes cannot be described by a `CONSTANT_Class_info`.
>> 
>> This patch restores a similar older behavior of using legal yet unusable class names.  Previously, the invalid `.` in hidden class names was replaced by a `/` as if a package separator; this patch changes it to a `_` like that in the generated lambda's class name.
>> 
>> The bug report shows some unintended and erroneous usages of `LambdaMetafactory`.  To clarify and to persuade against misuse, I added a paragraph of API notes to `LambdaMetafactory`, describing the impact of this API being designed to support Java language features.  In particular, I used the scenario where people assumed LMf generates weak hidden classes, which happened in this issue report and in #12493, that misuse can lead to resource leaks.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Wording as discussed

src/java.base/share/classes/java/lang/invoke/LambdaMetafactory.java line 243:

> 241:  * caller.  This technique reduces heap memory use, but it prevents the
> 242:  * implementation class from unloading when the caller is a {@linkplain
> 243:  * MethodHandles.Lookup.ClassOption#STRONG hidden class} and is unloaded.

Sorry but, the text still doesn't seem right to me. The caller class is unloaded when its class loader is unloaded, which would also be when the implementation class is unloaded (it's tied to the caller's class loader because of STRONG). Whether the caller is a hidden class (STRONG or not), should not matter... The point is that the _implementation class_  is a STRONG hidden class, so its lifetime gets tied to the caller's class loader.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21912#discussion_r1840933036