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

[Maurizio Cimadamore]

On Thu, 28 Apr 2022 18:36:48 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.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Avoiding a use of a new flag to determine Object methods copied to interfaces.

Looks good. I think I'm now convinced that this change does not make things worse, and that the changes in 8272564, while potentially breaking, do make the compiler more explicitly in sync with the JLS, so let's try to keep them in place. I agree with @lahodaj analysis that, if needs be, we can just rollback the codegen part of 8272564.

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

Marked as reviewed by mcimadamore (Reviewer).

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