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.