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

[Jorn Vernee]

On Tue, 12 Nov 2024 18:00:01 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/lmf-hidden-serial-class-format
>  - Update docs per suggestion
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/lmf-hidden-serial-class-format
>  - Add a test to ensure serializable lambda creation and basic execution in hidden classes
>  - Specify consequence
>  - 8343064: ClassFormatError: Illegal class name from InnerClassLambdaMetafactory

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

> 242:  * implementation class from unloading when the caller is a {@linkplain
> 243:  * MethodHandles.Lookup.ClassOption#STRONG hidden class} and is unloaded, or when
> 244:  * the returned call site is no longer strongly reachable.

I don't get the last part of the sentence here. When the call site is no longer reachable _that_ prevents the class from being unloaded?

I like the implNote though. Maybe: "This technique reduces heap memory use, but it prevents the implementation class from being unloaded independently of its defining class loader" ?

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

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