Comment 1 Mikael Cluseau 2004-12-15 16:58:51 EST

I agree with Kent in his case, but my case it most likely the following one :

interface I<E extends Comparable<E>> {
   public >>E<< test(E element);
}
class A implements I<Integer> {
   public >>Integer<< test(Integer i) {}
}
class B extends A {
   public >>Comparable<< test(>>Comparable<< i) {}
}

Isn't there an obvious name clash because of the return type ?

Comment 2 Mikael Cluseau 2004-12-15 17:02:45 EST

I would also that it is only generics-related, because in Java 1.4 you can't
even have this :

class A {
   public Comparable test(Comparable c);
}

class B {
   public Integer test(Integer i);
}

... and only because it is a kind of generics.

Comment 3 Philipe Mulet 2004-12-16 04:09:19 EST

Actually, Kent, should it diagnose a nameclash due to conflict with bridge
method from A ?

Comment 4 Kent Johnson 2004-12-16 10:36:13 EST

Mikael - return types are not considered when looking for name clashes, since 
its only the parameters which decide the correct method to dispatch.

Philippe - I have yet to see any case when the bridge method was used for 
comparison.

Comment 5 Kent Johnson 2005-01-10 12:28:25 EST

Another case that causes a name clash with javac:

class E extends F<E> {
  public int compareTo(Object o) { return 0; }
  // name clash: compareTo(java.lang.Object) in E and compareTo(U) in I<E>
  // have the same erasure, yet neither overrides the other
}

abstract class F<T extends F<T>> implements I<T>{
  public final int compareTo(T o) { return 0; }
}

interface I<U>{
  int compareTo(U o);
}

But since E inherits from F that provides a valid implementation of compareTo
(F) and a bridge method for compareTo(Object), I don't see why E.compareTo
(Object) would cause a name clash.

This is a simplified case from bug 80626

Comment 6 Kent Johnson 2005-02-01 11:51:04 EST

Reworked our name clash detection.

Added MethodVerify test034

Comment 7 David Audel 2005-02-16 06:34:47 EST

Verified in I20050215-2300