On Wed, 13 Nov 2024 17:01:14 GMT, Chen Liang <li...@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
