Integrated: 8356942: invokeinterface Throws AbstractMethodError Instead of IncompatibleClassChangeError

[David Holmes]

On Thu, 3 Jul 2025 22:11:55 GMT, David Holmes <dholmes at openjdk.org> wrote:

> In [JDK-8186092](https://bugs.openjdk.org/browse/JDK-8186092) (way back in JDK 10) we elided loader constraint checks for overpass methods related to default methods by skipping them when initializing the itable for the interface. But that was the wrong place to do that. The overpass method is setup when there is a resolution/selection error so that the correct exception is thrown if the problematic method is invoked (like the ICCE reporting conflicting methods) and by eliding that entry we instead get the `AbstractMethhodError`.
> 
> The fix here is to revert that change from [JDK-8186092](https://bugs.openjdk.org/browse/JDK-8186092), and to address the loader constraint problem by adding the same check for overpass methods in `klassItable::check_constraints` that exists for `klassVtable::check_constraints`.
> 
> Testing:
>  - modified existing regression test
>  - tiers 1-4
> 
> EDIT: originally there was a new regression test for this, but this area is already covered by the `vmTestBase` "`defmeth` tests. That test was missing the necessary invocation modes to expose the bug, so they have been added.
> 
> Thanks
> 
> PS. The diff is much smaller if you disable whitespace differences.

This pull request has now been integrated.

Changeset: f36147b3
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f36147b3263662229e9a0ec712b9748711d2d85d
Stats:     71 lines in 2 files changed: 12 ins; 2 del; 57 mod

8356942: invokeinterface Throws AbstractMethodError Instead of IncompatibleClassChangeError

Reviewed-by: coleenp, iklam

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

PR: https://git.openjdk.org/jdk/pull/26122