abstract method in indirect superclass

[Remi Forax]

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 
javac
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.

cheers,
Rémi

> 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 (§8.4.8.1) it."
>
> Interpreting this sentence *in the context of C*, I see a method
> foo(T3) with no legal implementation.
>
> Finally, 0.6.2 sect. 8.1.1.1 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