-
Bug
-
Resolution: Fixed
-
P4
-
1.4.0
-
1.4
-
generic
-
solaris_8
-
Verified
In 8.6.4.1, it says
An instance method m1 declared in a class C overrides another method with the same signature, m2, declared in class A if
both
1.C is a subclass of A.
2.Either
o m2 is non-private and accessible from C, or
o m1 overrides a method m3, m3 distinct from m1,
m3 distinct from m2, such that m3 overrides m2.
My question has to do with the phrase "accessible from C". Does this
mean accessible in code within the class C when accessing as a member of A,
or does it mean is an accessible member of C? There is a difference when the
member is not inherited into C. The resolution of 4362349 depends on the
interpretation of this phrase.
Recent discussions have suggested that this means either
(1) m2 is a member of C accessible to code in C, or
(2) m2, as a member of A, is accessible to code in C
Neither definition is very satisfying. If definition (1) is the
one we should use in the compiler, then 4362349 is indeed a compiler bug
and I know how to fix it. But then the following program will
be a compile-time error:
package p1;
abstract class A {
abstract protected f();
}
package p2;
class C extends p1.A {
protected f() {}
}
The compiler will complain that class C should be declared abstract
because it doesn't override f() in A. That's because A.f isn't
accessible in C because the qualifying type, A, isn't C (JLS 6.6.2.1).
So I'm back to the drawing board trying to understand 8.6.4.1.
An instance method m1 declared in a class C overrides another method with the same signature, m2, declared in class A if
both
1.C is a subclass of A.
2.Either
o m2 is non-private and accessible from C, or
o m1 overrides a method m3, m3 distinct from m1,
m3 distinct from m2, such that m3 overrides m2.
My question has to do with the phrase "accessible from C". Does this
mean accessible in code within the class C when accessing as a member of A,
or does it mean is an accessible member of C? There is a difference when the
member is not inherited into C. The resolution of 4362349 depends on the
interpretation of this phrase.
Recent discussions have suggested that this means either
(1) m2 is a member of C accessible to code in C, or
(2) m2, as a member of A, is accessible to code in C
Neither definition is very satisfying. If definition (1) is the
one we should use in the compiler, then 4362349 is indeed a compiler bug
and I know how to fix it. But then the following program will
be a compile-time error:
package p1;
abstract class A {
abstract protected f();
}
package p2;
class C extends p1.A {
protected f() {}
}
The compiler will complain that class C should be declared abstract
because it doesn't override f() in A. That's because A.f isn't
accessible in C because the qualifying type, A, isn't C (JLS 6.6.2.1).
So I'm back to the drawing board trying to understand 8.6.4.1.
- relates to
-
JDK-4362349 Cannot override abstract method in same package
- Closed
-
JDK-4485402 Wrong implementation of definition of "override"
- Closed
-
JDK-4493343 wrong implementation of "inheritance" and "accessibility of methods"
- Closed