RFR: 8356942: invokeinterface Throws AbstractMethodError Instead of IncompatibleClassChangeError [v2]

[David Holmes]

On Tue, 8 Jul 2025 11:55:21 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replaced new test by updating existing defmeth case that was missing the invokeinterface variants of the
>>   test scenario. Also updated all tests therein to use `throwsExact` so that the wrong kind of ICCE does not
>>   cause the test to pass by mistake.
>
> test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/ConflictingDefaultsTest.java line 86:
> 
>> 84:      * TEST: C c = new C(); c.m() ==> ICCE
>> 85:      * TEST: I c = new C(); c.m() ==> ICCE
>> 86:      * TEST: J c = new C(); c.m() ==> ICCE
> 
> So this is the generator code that generates the defmeth tests, but iirc, the tests are regenerated and the generated tests were the ones checked in and run.
> 
> And shouldn't the test from commit 87e30fd80172c5bd6748f140ddf6cd19adb62764 now fail?

I'm not aware of any checked in generated tests. I added the new tests here and they run.

Why should the test for loader-constraints fail? I fixed that issue just in a different way to the original fix. Hence the test passes as it should.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26122#discussion_r2192351727