abstract method in indirect superclass

[Remi Forax]

On 07/07/2013 05:03 PM, Stephan Herrmann wrote:
> On 07/07/2013 04:44 PM, Remi Forax wrote:
> > I don't see how this can compile despite the fact that both eclipse 
> and javac
> > are happy with this code :(
>
> In fact this surfaced because a recent clean-up in ecj incidentally
> changed this behavior so in 4.3 we no longer accept such code.
>
> > foo(A) does not override foo(T2) if by example T2 is B so it should 
> result in a name clash.
>
> I don't think this part is at stake.
> The signature of foo(A) is a subsignature of the signature of foo(T2)
> because the former equals the erasure of the latter.

it should because this is obviously a bug,
this code throws a CCE

    class A { }
    class B extends A { }
    class C extends A { }

   abstract class X1<T1 extends A> {
       void foo(T1 t) {
         System.out.println("X1");
       }
   }
   class X2<T2 extends A> extends X1<T2> {
       @Override void foo(A t) {
         System.out.println("X2");
       }
   }
   class X3 extends X2<B> {
     @Override void foo(B t) {
       System.out.println("X3");
     }
   }

   public class Test {
     public static void main(String[] args) {
       X2<B> x2 = new X3();
       x2.foo(new C());
     }
   }

Rémi

>
> Only what's going on in X3 is unclear in JLS7. My questions are
> whether the change made for JSR 335 has been made consciously and
> whether any changes should be made to compilers for Java 7-.
>
> thanks,
> Stephan
>
>