There is some laxity in the verifier when it comes to checking interface method calls, compared to non-interface calls. This has led to some missing receiver type checks in the VM invocation paths and MethodHandle invocation paths, which have been fixed over time. There remains an issue with invokespecial of interface methods.

JDK-8168699 dealt with direct bytecode invocation modes (ie invokespecial) but did not make any changes to Methodhandle invocations. JDK-8174962 made further changes for invokeInterface, including MethodHandle invocation, but private interface methods use invokeSpecial. So the case of a MethodHandle based invokeSpecial invocation is not covered.

If we take the test written for 8174962 and adapt it to use private methods then we hit an assertion failure during MethodHandle verification:

# Internal Error (/export/users/dh198349/jdk-hs/open/src/hotspot/cpu/x86/macroAssembler_x86.cpp:895), pid=7516, tid=7545
# assert(false) failed: DEBUG MESSAGE: receiver class disagrees with MemberName.clazz
#

The low-level check has detected the incorrect receiver type that should actually be detected at a higher level and IncompatibleClassChangeError thrown.