Compiler allows incompatible methods to override methods in indirect superclass

In the example below, the methods m1, m2, m3 in C have the same signatures
as the respective methods in A. A and C are declared in the same package,
and the methods of A all have default access, thus making them accessible
from C. Hence, by 8.4.6.1, the methods in C override those of A.
 
1. The private modifier of method m3 declared in C does not cause a compiler error. It should, per 8.4.6.3.
 
2. The return type int of method m2 declared C does not cause a compiler error.
It should, per 8.4.6.3.
 
 
package lib;
 
public class A {
    public void show() { m1(); m2(); m3(); }
    void m1() { System.out.println("A1"); }
    void m2() { System.out.println("A2"); }
    void m3() { System.out.println("A3"); }
}
 
package pkg;
 
public class B extends lib.A {
    void m1() { System.out.println("B1"); }
    void m2() { System.out.println("B2"); }
    void m3() { System.out.println("B3"); }
}
 
package lib;
 
public class C extends pkg.B {
    void m1() { System.out.println("C1"); }
    int m2() { System.out.println("C2"); return 0; }
    private void m3() { System.out.println("C3"); }
 
    public void test() {
        ((A)this).m1();
        ((A)this).m2();
        ((A)this).m3();
    }
}
 
//the following class is in the default package
 
public class Test {
    public static void main(String[] args) {
        new lib.C().show();
        new lib.C().test();
    }
}
 
Output from Test:
C1
A2
A3
C1
A2
A3

Given that the compiler accepts the code without error, the run time behaves
more or less as expected (though C.m3 should still override A.m3, but it's
easy to see why this happens).

###@###.### 2002-08-07