Community
Participate
Working Groups
I am using the latest AJDT (1.5.2.200804031719) from 3 Apr 2008. Also I am compiling with Java 1.6.0_03 under 5.0 compliance. This bug occurs in the following example code (also attached): //BarAspect package a; import b.Bar; import b.Foo; public aspect BarAspect { declare parents : Foo implements Bar; } //Bar package b; import java.util.Collection; public interface Bar { public Collection<Foo> getFoos(); } //Foo package b; import java.util.ArrayList; import java.util.Collection; public class Foo { public Collection<Foo> getFoos() { return new ArrayList<Foo>() {{ add(new Foo()); }}; } } When using Eclipse, Foo.java fails to compile with the following error: "The return type is incompatible withe b.Bar.getFoos()". This bug only occurs in Eclipse and works when running the AspectJ compiler from the command line. The following conditions seem necessary to reproduce this bug: *Aspect (BarAspect) and type being advised (Foo) are in different packages *The implementation of the interface (Bar) is already done by the type being advised (Foo) *The return type of a method in the interface is generic When the implementation is advised into the type (Foo), then the error does not appear. Also, when the type (Foo) is moved to the same package as the aspect (BarAspect), the error goes away as well. Only when the combination of the previous three conditions exists does the bug appear.
This actually appears to occur when running iacj from Ant as well, unlike I previously indicated.
Created attachment 95604 [details] Test case
thanks for the clear test program. It is an ordering issue - I can make it fail with the command line compiler by compiling: ajc -1.5 BarAspect.java Foo.java Bar.java but it works with ajc -1.5 BarAspect.java Bar.java Foo.java That is because of the pipelining compiler. To make it work right now a simple workaround for now is to turn off pipeline compilation. In a pipeline types can sometimes be Bcel entities and sometimes be Eclipse entities. In a non-pipeline compilation they are all bcel entities. When they are a mixture, the return type of the super-method (captured from the eclipse member) is Collection<Foo> whilst the sub-method (captured from the bcel member) is Collection. They are considered incompatible. When they are all bcel entities, Collection and Collection are considered the same and the weave is successful. The fix will be to get the real parameterized return type from the bcel member (Collection<Foo>).
Thanks for the clarification. The work-around does seem to work appropriately.
Created attachment 96891 [details] Workspace patch (tests/weaver) - fixes this bug
Fixes committed - they will be in the next dev build and in AspectJ1.6.1