Along with direct nestmate support the JVMS changes to invokeinterface affect existing SelectionResolution tests.

For example, InvokeInterfaceICCE expects invokeinterface of a private method to throw ICCE because invokespecial is required to be used. But now invokeinterface is used instead so ICCE is not thrown. Hence this block had to be removed from the test:

! /* Group 175: private method in interface */
! new TestGroup.Simple(initBuilder,
! Template.SetInvoke(SelectionResolutionTestCase.InvokeInstruction.INVOKEINTERFACE),
! Template.ResultCombo(EnumSet.of(Template.Kind.INTERFACE),
! EnumSet.of(MethodData.Access.PRIVATE),
! EnumSet.of(MethodData.Context.INSTANCE),
! EnumSet.of(ClassData.Package.SAME)),
! Template.OverrideAbstractExpectedIface,
! Template.MethodrefEqualsExpected,
! Template.IgnoredAbstract,
! Template.CallsiteEqualsMethodref,
! Template.IfaceMethodrefSelection)

so that it passes. But if I paste that block into the InvokeinterfaceSuccess test then that test fails.

Unfortunately the SelectionResolution tests are extremely hard to understand, and I can't tell from the error exactly what goes wrong. I suspect that this test block covers a multitude of test conditions, only a subset of which are affected by the change. So somehow the affected tests need to be extracted so that we can move only the appropriate ones to the "success" test.

Similarly the skipping of private methods when selecting the implementation to call for a resolved public method will require changes to other SelectionResolution tests.