RFR: 8374654: Inconsistent handling of lambda deserialization for Object method references on interfaces

Wed Jan 7 20:23:50 UTC 2026

On Tue, 6 Jan 2026 23:26:35 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> See [JDK-8374654](https://bugs.openjdk.org/browse/JDK-8374654). This fixes an inconsistency between generated Lambda `$deserialization$` methods and the runtime behaviour of `SerializedLambda` instances, for Object method references on interfaces. At runtime the methods are resolved to declared methods, so Object method references on interfaces will always have the `getImplMethodKind`, `getImplClass`, and `getImplMethodSignature` of the method declared in `Object`, not of an override in the interface.

Thanks for the detailed comment! I think that generally matches my understanding from the history I read up on.

> In short, as far as I know, there are quite a few cases where (de)serialization of method references misbehaves. And changes around this area tend to cause regressions, often regressions that are found quite late.

This definitely makes sense. It may be the case that it doesn't make makes to make incremental changes here, rather than waiting for a longer term plan like JDK-8068253.

I have been seeing a handful of issues with the same root cause as JDK-8208752, which this change together with #28943 was working towards fixing. I was somewhat optimistic that these two fixes but improve on the status quo. I am going to do more internal testing on Google's corpus. We have a lot of code that serializes lambdas and method references, so I'll see if I can get any signal from that.

> javac will (now) use a sharp method reference in the bootstrap's arguments (note the `REF_invokeInterface Main$I2.hashCode:()I`

To double-check: when you saw 'now', do you mean recent versions of javac (I think this may have changed after JDK-8282080 / JDK-8272564), or that there was a change in that area in this PR? This PR shouldn't have changed the bootstrap arguments, just `$deserializeLambda$`

> Note the `instantiatedMethodType` (in `SerializedLambda`) here is different between the two method references used in this testcase, so one possibility would be to also check the value of that to disambiguate between the references.

That is what I was investigating in #28943 as a possible fix for JDK-8208752, and I double-checked it fixes your second example. When I was investigating JDK-8208752 that uncovered this issue with the handling of Object methods, which I split out. It looks like it probably doesn't make sense to make this change by itself, or at least not unless it's immediately followed by #28943 or something else that would fix cases like your repro.

On the other options:

> wait for https://bugs.openjdk.org/browse/JDK-8068253

JDK-8068253 seems appealing, I wasn't sure what the prospects for that are. [This comment](https://bugs.openjdk.org/browse/JDK-8068253?focusedId=14049610&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14049610) mentions having the existing `getDeclaringClass` return the referenced class, which I think is an easy implementation change, but I don't have a good sense of the compatibility impact.

> simply expand all serializable method references to lambdas

This option was also mentioned in [this comment in JDK-8154236](https://bugs.openjdk.org/browse/JDK-8154236?focusedId=14024713&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14024713), it seems like it might have more compatibility implications.

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

PR Comment: https://git.openjdk.org/jdk/pull/29075#issuecomment-3720628758