abstract method in indirect superclass

Remi Forax forax at univ-mlv.fr
Sun Jul 7 07:44:08 PDT 2013

On 07/07/2013 02:30 PM, Stephan Herrmann wrote:
> Hi,
> 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) { }
>   }

I don't see how this can compile despite the fact that both eclipse and 
are happy with this code :(
foo(A) does not override foo(T2) if by example T2 is B so it should 
result in a name clash.


> 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.
> thanks,
> Stephan

More information about the lambda-spec-experts mailing list