Actually it looks to me like AspectJ
is behaving as expected. I quote from the "Static crosscutting"
section of the AspectJ Programming Guide where it discusses conflicts (see
"Conflicts are resolved as much
as possible as per Java's conflict resolution rules ... A subclass can
only inherit multiple methods with the same name and argument types
from its superclasses if only zero or one of them is concrete (i.e., all
but one is abstract, or all are abstract)."
It looks like your aspect is creating
a situation where type SubclassData is going to inherit two concrete methods
- one from the super class BaseClass and one from the interface IToString.
If you wanted to "inject" a method override for the toString()
method then you could just change the method introduction to be
public String SubclassData.toString()
"eliminated commons-lang dependency for testcase";
I think there is still something more
to be explained here though. Just as I was about to press send on
the above response, I noticed that, with your original code still in place,
removing the implementation of toString() from BaseClass resulted in the
compiler error going away. Which is surprising (to me anyway) since the
class SubclassData is surely still inheriting the toString() method from
its more distant ancestor java.lang.Object. Perhaps java.lang.Object is
a special case in the Java conflict resolution rules. Now, where did I
put that language spec ... ?
George C. Harley
<lee.sanders@xxxxxxxxxxxxxxx> Sent by: aspectj-users-admin@xxxxxxxxxxx
Please respond to
"Lee Sanders" <lee.sanders@xxxxxxxxxxxxxxx>
[aspectj-users] problem with inter-type
declaration - inserting a method override
Problem: I want to statically add a toString method
into a specified set of
I'm having a problem with the ajc 1.2.1 compiler in the case where the
defines a toString method. It says there is a conflict with an existing
I've created a simplified test case below to concretely illustrate the
So is this some kind of correct limitation in the aspectj language that
missed? It seems like this is a natural way of injecting method overrides
any superclass method implementation(s)...