RFR: 8282080: Lambda deserialization fails for Object method references on interfaces

[Maurizio Cimadamore]

On Thu, 31 Mar 2022 08:13:57 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Per JLS, every interface with no superinterfaces implicitly has all public methods `java.lang.Object` has (unless the interface declares them explicitly). So, having:
> 
> interface I {}
> 
> the interface has methods like `hashCode()`. But, before https://bugs.openjdk.java.net/browse/JDK-8272564, javac was referring to them as if they were a `java.lang.Object` methods, not the interface methods. E.g. saying `I i = null; i.hashCode()` lead to a reference to `java.lang.Object.hashCode()` not `I.hashCode()`. That was changed in JDK-8272564, and now the reference is to `I.hashCode()`.
> 
> There is one issue, though: when the reference is for a serializable (and serialized) method handle, the runtime method is still `java.lang.Object::hashCode`, but the deserialization code generated by javac expects `I::hashCode`, and hence the serialized method handle fails to deserialize.
> 
> The proposal here is to fix just this case, by changing the deserialization code to expect the method from `java.lang.Object`, which should revert the deserialization behavior back to JDK 17 behavior.

Actually, my reading of the JLS is incorrect. JLS says that the type of the binary qualifier is the type of the class in which the method has been declared, either explicitly, or implicitly. For interfaces, Object methods are declared implicitly by the interface, so it would seem that the type of the binary qualifier in this case is indeed the interface type, and that JDK-8272564 rectified that issue.

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

PR: https://git.openjdk.java.net/jdk/pull/8054