Comment 1 Andrew Eisenberg 2009-01-23 17:58:22 EST

Created attachment 123608 [details]
Project that exhibits this behavior

Comment 2 Andrew Clement 2009-01-23 21:58:09 EST

yikes... is that really the smallest testcase you have...  there are two source
folders and umpteen types... when only 4 things are involved it seems (the
interface, the implementor, the aspect and the other bound, Type1).  Here is a
much simpler file with the same behaviour:

---
import java.util.*;

interface I {
        public <T> List<T> getStuff();
}

class C<D extends Set> implements I {
        public <T extends D> List<T> getStuff(){
                return new LinkedList<T>();
        }
}

aspect X {
        public <T> List<T> I.getStuff(){
                return new ArrayList<T>();
        }
}
---

This should actually be a compile time error, there is no missing relationship
because it should not compile.  If you had looked with javap -private on the
GenericMethodImpl you'd see that the compile did not include the variant of the
method that returns an ArrayList in the woven target class - although an
erroneous weavinfo message will come out if you use -showWeaveInfo.  (I suspect
indicating a match occurred but not a weave)

You cannot have two methods in the target type with the same erasure, it is a
name clash - exactly as attempted in this pure java program:

---
import java.util.*;

interface I {
        public <T> List<T> getStuff();
}

class P implements I {
  public <T> List<T> getStuff() { return new LinkedList<T>();}
}

class C<D extends Set> extends P {
        public <T extends D> List<T> getStuff(){
                return new LinkedList<T>();
        }
}
---

Generic ITDs 1\src\Y.java:12 [error] Name clash: The method getStuff(
) of type C<D> has the same erasure as getStuff() of type P but does not
override it public <T extends D> List<T> getStuff(){
                             ^^^^^^^^
1 error

And if the ITD can manage to get onto an intermediate class in the hierarchy:

---
import java.util.*;

interface I {
        public <T> List<T> getStuff();
}

class P implements I {}

class C<D extends Set> extends P {
        public <T extends D> List<T> getStuff(){
                return new LinkedList<T>();
        }
}

aspect X {
        public <T> List<T> I.getStuff(){
                return new ArrayList<T>();
        }
}
---
this reports the same name clash.  So the bug is that if the top-most
implementor contains an name clash there should be a name clash compilation
error.

Comment 3 Andrew Clement 2009-01-23 22:21:44 EST

bug is around ResolvedType.compareToExistingMembers() since that checks, when an intertype decl is added to a topmost implementor, whether the new member clashes with an existing one.

Comment 4 Andrew Clement 2009-02-09 15:20:53 EST

testcode committed for this - commented out in Ajc164tests

Comment 5 Andrew Clement 2013-06-24 11:08:18 EDT

unsetting the target field which is currently set for something already released