RFR: 8208752: Calling a deserialized Lambda might fail with ClassCastException [v4]

[Liam Miller-Cushon]

On Thu, 29 Jan 2026 18:13:44 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:
>> 
>>  - Merge branch 'JDK-8374654' into JDK-8208752
>>  - Test cleanup
>>  - Updates for --debug=dumpLambdaDeserializationStats
>>  - Merge branch 'JDK-8374654' into JDK-8208752
>>  - Merge branch 'JDK-8374654' into JDK-8208752
>>  - Update test
>>  - Merge branch 'JDK-8374654' into JDK-8208752
>>  - Don't rely on the iteration order of Map.of entries
>>  - 8208752: Calling a deserialized Lambda might fail with ClassCastException
>
> I have a question: [1] refers to [2] as a possible cause. But actually [2] only did a javadoc change specifying that the identity of a function object produced from a lambda expression or method reference (specifically that produced by the invocation of the LambdaMetafactory's CallSite's target) or produced by deserialization of a serialized lambda can be unpredictable.
> 
> so it seems like the spec acknowledges that there shouldn't be any assumption that what enters serialization should be equal to what comes out. So two different lambdas after serialization could be equal to each other. Of course this applies more to bug [3] who's PR is now part of this one
> 
> [1] https://bugs.openjdk.org/browse/JDK-8208752
> [2] https://bugs.openjdk.org/browse/JDK-8202922
> [3] https://bugs.openjdk.org/browse/JDK-8374654

@vicente-romero-oracle that is a good point. To be clear I didn't report JDK-8208752, so I can't vouch for what the thinking behind that text was, but I wonder if "this is probably a side effect of JDK-8202922" refers more to it being related to the behaviour discussed in JDK-8202922, than specifically a culprit of the changes in the other bug.

My understanding overall is that the spec gives the compiler latitude to merge equivalent lambdas or method references together during serialization, but the key part is that they have to be equivalent, and the issue being fixed here is a case where the merging was incorrectly combining lambdas with different target types.

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

PR Comment: https://git.openjdk.org/jdk/pull/28943#issuecomment-3822586594