Community
Participate
Working Groups
ITD ignores methods from the declared interface implementation if they are already implemented in the super class of the aspected class. A test case is attached: Method a() will never be generated into B, since it already implemented in the super class A.
Created attachment 34189 [details] aop-test.zip
This looks like another case of @AJ decp not behaving like it would if you did it in code style. Under code style the implementation on the subtype is via ITD public void B.a() { System.out.println("---a---"); } and if you do it that way, it works as expected - with the introduced method overriding that in the supertype.
Unfortunately my client is not using Eclipse, so the only option for him is to use @AJ...
I didn't say it wasnt a bug - it is and it needs fixing if thats possible within the current design of @decp.
Remember that @DeclareParents has declare ... implements semantics, not declare ... extends. With implements, the given method declaration is treated as a default implementation to be used if the target type does not provide its own. So the test case is analoguos to the following aspectj program: public class TestDP extends Super { public static void main(String[] args) { new TestDP().a(); } } class Super { public void a() { System.out.println("Super.a"); } } aspect DP { interface I { void a(); } public void I.a() { System.out.println("DP.a"); } declare parents : TestDP implements I; } Which raises an interesting semantics issue. The program above fails to compile (!) warning that the ITD conflicts with existing member Super.a(). I don't believe this should be the case - it is not a conflict as we have declare ... implements semantcis. So there is still a bug here...
fwiw, I believe Adrian's code sample *is* a conflict, as defined by the semantics appendix section on point: "Conflicts may occur from ambiguously inheriting members from a superclass and multiple superinterfaces." It would not be a conflict if the existing implementation were in the target class (target class wins over inherited interface implementation) or if the declaration were on the target class (declaration overrides supertype implementation). It should also be a conflict if there are declarations of the same member in multiple interfaces implemented by the target class.
I noticed that this bug raises semantic debates, so it has not been assigned yet. On the practical side, many (arguably, poorly written) 3rd party frameworks, including the framework I needed to use, use null implementations that need be overridden by the developer. I was looking to automate this overriding process with AJ. Adrian's point of view wrt "implements" semantic seems logical to me since it behaves like normal java code. This is also the approach taken by AspectWerkz mixins (which I eventually ended up using).
Works as expected in 1.5.1_a
My bad (ran wrong tests). Still mismatch between @aj and code style.
