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.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java line 758:

> 756:         String functionalInterfaceMethodName = samSym.getSimpleName().toString();
> 757:         String functionalInterfaceMethodSignature = typeSig(types.erasure(samSym.type));
> 758:         if ((refSym.flags_field & OBJECT_METHOD_IN_INTERFACE) != 0) {

Instead of using a new flag, can we use the base symbol and check if its owner is Object?

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

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