On Tue, 12 Nov 2024 18:00:01 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 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
