Summary

The fix for JDK-8059632 caused a regression in method reference serialization and deserialization. Given the complex nature of the problem, the proposal is to revert the JDK-8059632 fix, and re-apply it in a future version, together with possible fixes for serialization, if and as needed.

Problem

Considering code like:

static class E {
    public boolean test(Object o) { return false; }
}

static class F extends E implements Serializable  {
}

...

F e = new F();
Predicate<E> p = (Serializable & Predicate<E>) e::test;

Before JDK-8059632, the classfile reference corresponding to e::test in the source code was E::test. That is wrong per JLS 13.1, the reference should be to F::test, which JDK-8059632 fixed. As a consequence, however, if the value in p is serialized, it can no longer be deserialized, even by the very same classfile and JDK.

Solution

Given the release timing, and overall complexity of fixes in (de-)serialization code for method references, the proposal is to revert the fix for JDK-8059632, evaluate the impact on serialization, and re-apply the fix with any further changes for serialization deemed necessary in a future version.

Specification

Classfile references corresponding to source code method references will revert to pre-JDK-8059632, i.e. JDK 19, form. This form does not adhere to the JLS 13.1 wording, but it is a long-standing behavior.