[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-compiler-dev
Subject:    Re: RFR: 8282080: Lambda deserialization fails for Object method references on interfaces [v2]
From:       Liam Miller-Cushon <cushon () openjdk ! java ! net>
Date:       2022-04-30 19:39:33
Message-ID: zRvzXaRa4PhOokdDj5Vf8brpa7zvrxq3trkhSYmBQOQ=.d4199c2a-ed53-4a4a-9b7c-57a8501b2c4e () github ! com
[Download RAW message or body]

On Thu, 28 Apr 2022 18:36:48 GMT, Jan Lahoda <jlahoda@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.

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.

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

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


[prev in list] [next in list] [prev in thread] [next in thread]