On Thu, 22 Jan 2026 11:45:08 GMT, Liam Miller-Cushon <[email protected]> wrote:
>> See [JDK-8208752: Calling a deserialized Lambda might fail with >> ClassCastException](https://bugs.openjdk.org/browse/JDK-8208752). >> >> Lambda deserialization currently does not consider >> `SerializedLambda#getInstantiatedMethodType` when deserializing lambdas, >> which can lead to method references that differ only in >> `getInstantiatedMethodType` being merged into the same lambda instance, and >> can result in `ClassCastException`s like the one reported in the bug. >> >> This depends on the fix for [JDK-8374654: Inconsistent handling of lambda >> deserialization for Object method references on >> interfaces](https://bugs.openjdk.org/browse/JDK-8374654) in >> https://github.com/openjdk/jdk/pull/29075. > > 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 [1] https://bugs.openjdk.org/browse/JDK-8208752 [2] https://bugs.openjdk.org/browse/JDK-8202922 ------------- PR Comment: https://git.openjdk.org/jdk/pull/28943#issuecomment-3819376530
