RFR: 8282080: Lambda deserialization fails for Object method references on interfaces [v2]
Jan Lahoda
jlahoda at openjdk.java.net
Thu Apr 28 18:36:48 UTC 2022
> 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.
-------------
Changes:
- all: https://git.openjdk.java.net/jdk/pull/8054/files
- new: https://git.openjdk.java.net/jdk/pull/8054/files/72281286..7bf7fedb
Webrevs:
- full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8054&range=01
- incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8054&range=00-01
Stats: 11 lines in 3 files changed: 2 ins; 6 del; 3 mod
Patch: https://git.openjdk.java.net/jdk/pull/8054.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/8054/head:pull/8054
PR: https://git.openjdk.java.net/jdk/pull/8054
More information about the compiler-dev
mailing list