Nestmates JVMS Overriding 5.4.5 request

[Karen Kinnear]

Dan Smith - this is a request for a change to one line of the Nestmates JVMS 5.4.5 Overriding.
The rest of the wording for 5.4.5 is an improvement, so thank you.

Dan Heidinga, Graham Chapman (IBM) and I met to discuss the JVM implementations of
JVMS 5.4.5 Overriding, specifically to discuss the expectations relative to the
bullet describing transitive overriding that was added for CFV 51 in JDK7.

The JVMS 9 bullet says:
 mC overrides a method m' (m' distinct from mC and mA) such that m' overrides mA.

The proposed NestMates bullet says:
mC overrides a method m' (m' distinct from mC and mA) such that m' overrides mA mA is marked neither ACC_PUBLIC nor ACC_PROTECTED nor ACC_PRIVATE, and, where mC is declared in a class C and mA is declared in a class A, there exists a method mB declared in a class B, such that C is a subclass of B, B is a subclass of A, mC can override mB, and mB can override mA.
From examining a number of test cases, we would like to request that the updated version be modified to remove the restriction on mA as package private. We need to perform what I call transitive overriding checks as long as mA is not ACC_PRIVATE.

Dan H also suggested it would be very helpful to all of us if you could add some non-normative examples in the spec here. Examples that might be useful would be:

1. reason we added transitive overriding to start with - see postscript

2. example of why we need to do the transitive overriding even if mA is public/protected as well as package private: (test 841 from our internal test matrix for invoke virtual)

>  841|   A PUB        a.B PP     b.C PUB
>  
> call A with B - B.m (B overrides A)
> call A with C - C.m (C overrides A)
> call B with C - B.m (C does not override B)


3. a fix we had to make in 2014:
P1.A: public m()
P2.B extends A, PP m()
P1.C extends B, public m()

P1.C.m() needs to override P1.A.m() and can not override P2.B.m()


thanks,
Karen

p.s. extract from JVMS Clarifications and Addenda to 2nd edition (since the original link is gone):

With classfile version 51, which is introduced in JDK7, the invokevirtual behavior will be fixed to match the clarifications in the JVMS which were made to handle the following test case:

Description of the original problem from: Why the Definition of Method Override was Revised:
package P1;

class A {
  void m(){System.out.println("A.m");}
  public void callM(){ m();}
}

public class B extends A {
   protected void m() { System.out.println("B.m");}
}

package P2;

class C extends P1.B {
  protected void m(){ System.out.println("C.m");}

  public static void main(String[] args) {
    C c = new C();
    c.callM();
}
Given the original definition of override, we find that the method m() declared in C overrides the method m() declared in B(), since it has the same name and signature and is accessible from class C. However, we a lso find that the method m() declared in C does not override the method m() declared in A(), since it is private to package P1 and therefore not accessible from class C.
In this case, invoking callM() on an instance of C causes a call of m() where the target of the method invocation is an instance of C as well. However, this call is in the class P1.A, and is attempting to invoke a package private method of A. Since this method is not overridden by C, the code will not print "C.m" as expected. Instead, it prints "B.m".
This is quite unintuitive, and also incompatible with the behavior of the classic VM.
We believe that this interpretation, while literally accurate, is undesirable. It prevents a package private method from ever being overridden outside its package, even if a subclass within the package has increased the method's accessibility.

Therefore invokevirtual was modified in JVMS Clarifications and Addenda to 2nd edition to: 

Let C be the class of objectref. The actual method to be invoked is selected by the following lookup procedure:

If C contains a declaration for an instance method M with the same name and descriptor as the resolved method, and M overrides the resolved method, then M is the method to be invoked, and the lookup procedure terminates.

Otherwise, if C has a superclass, this same lookup procedure is performed recursively using the direct superclass of C ; the method to be invoked is the result of the recursive invocation of this lookup procedure.

Otherwise, an AbstractMethodError is raised.

From the JVMS 2nd edition invokevirtual:

Let C be the class of objectref. The actual method to be invoked is selected by the following lookup procedure:

If C contains a declaration for an instance method with the same name and descriptor as the resolved method, and the resolved method is accessible from C, then this is the method to be invoked, and the lookup procedure terminates.

Otherwise, if C has a superclass, this same lookup procedure is performed recursively using the direct superclass of C ; the method to be invoked is the result of the recursive invocation of this lookup procedure.

Otherwise, an AbstractMethodError is raised.

Note: the key difference here is the phrase: "the resolved method is accessible from C" which in the Clarifications and Addenda has been replaced with "M overrides the resolved method"