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

[Jan Lahoda]

On Sat, 30 Apr 2022 19:36:25 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> Re: the impact of JDK-8272564, for what it's worth, it ended up being a noticeable breaking change for us:
> 
>     * Some static analysis that was looking for interfaces noticed the 'sharper' static type information on these calls. This is an improvement, but still a breaking one.
> 
>     * A non-OpenJDK runtime's verifier didn't handle the new calls (which is their bug, but confirms this is a slightly surprising edge case), and we ended up doing some bytecode munging to rewrite back to invokevirtuals for code affected by that.
> 
> 
> At this point we've absorbed the breaking change and I personally don't have any concerns with the new behaviour, I'm just sharing that in case you're still weighing the risk of whack-a-mole from keeping JDK-8272564.

JDK-8272564 has three parts:
1. the model was modelling mistake, where the AST was referring to a suboptimal element. In particular:

interface I {
     public String toString();
}
interface J extends I {}

I i = null;
i.toString(); //AST and classfile contain call to I.toString()
J j = null;
j.toString(); //AST and classfile contain call to j.l.Object.toString()


the attribution of `j.toString()` is obviously weird, and has then effects on various other parts of the model.

2. in the case above, the classfile was also referring to `j.l.Object.toString()` for `j.toString()`, which is also a bit weird.
3. for cases like:

interface K {}
K k = null;
k.toString();

the classfile was referring to `j.l.Object.toString()`, which strictly speaking does not adhere to JLS 9.2. (Interface Members), which says interfaces have the `public abstract` methods of `j.l.Object` (unless they declare them explicitly).

I believe this problem, and other problems were likely caused by fixing 3. I believe we did that mostly for consistency, and if needed we could revert this part.

I would really prefer to not revert 1., as that makes the model much less useful.

For 2., it is a bit related to 1., but we could revert that, although it is a bit more complex, and is unlikely to be causing problems.

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

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