abstract method in indirect superclass

Stephan Herrmann stephan.herrmann at berlin.de
Sun Jul 7 05:30:03 PDT 2013


I'm currently investigating an issue of required overriding of
an abstract method, illustrated by this example:

   class A { }
   class B extends A { }

   abstract class X1<T1 extends A> {
       abstract void foo(T1 t);
   abstract class X2<T2 extends A> extends X1<T2> {
       @Override void foo(A t) { }
   class X3<T3 extends B> extends X2<T3> { }

The question is whether or not X3 must provide an implementation
of "void foo(T3)", i.e., should an error be flagged against X3,
because it does not inherit nor implement a method whose signature
is a subsignature of "(T3)"?

The way I read the 0.6.2 spec, the answer is "no", because X3
can only inherit methods from its direct superclass X2, but not
from X1. Since X2 overrides foo, the abstract version is not
relevant for X3.

OTOH, in my intuitive understanding of JLS7 the following sentence
would apply:

"Any of C's superclasses has an abstract method and C neither declares
  nor inherits a method that implements (§ it."

Interpreting this sentence *in the context of C*, I see a method
foo(T3) with no legal implementation.

Finally, 0.6.2 sect. says:
"Discussion and motivation:
     These changes are not meant to substantively change the definition
     of an abstract class, but rather to clarify the existing meaning."

By this comment, are you saying that the new interpretation has
always been intended and the above example should be accepted for all
versions of Java? Maybe this specific situation deserves a mentioning
in this paragraph of discussion?

Technically, the subsignature rule sneaks in a flavor of
contravariant overriding, which probably wasn't explicitly intended,
but at least it should cause no problems wrt soundness.


More information about the lambda-spec-experts mailing list