Bug 226567 - Inter-type declaration with generic return type across packages causes return type incompatibility
Summary: Inter-type declaration with generic return type across packages causes return...
Status: RESOLVED FIXED
Alias: None
Product: AspectJ
Classification: Tools
Component: Compiler (show other bugs)
Version: DEVELOPMENT   Edit
Hardware: PC Windows XP
: P2 critical (vote)
Target Milestone: 1.6.1   Edit
Assignee: AJDT-inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-04-10 13:01 EDT by Michael Huffman CLA
Modified: 2008-04-24 00:31 EDT (History)
3 users (show)

See Also:


Attachments
Test case (4.33 KB, application/x-zip-compressed)
2008-04-10 18:19 EDT, Michael Huffman CLA
no flags Details
Workspace patch (tests/weaver) - fixes this bug (9.00 KB, text/plain)
2008-04-21 13:02 EDT, Andrew Clement CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Huffman CLA 2008-04-10 13:01:28 EDT
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.
Comment 1 Michael Huffman CLA 2008-04-10 14:15:33 EDT
This actually appears to occur when running iacj from Ant as well, unlike I previously indicated.
Comment 2 Michael Huffman CLA 2008-04-10 18:19:59 EDT
Created attachment 95604 [details]
Test case
Comment 3 Andrew Clement CLA 2008-04-11 00:46:23 EDT
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>).
Comment 4 Michael Huffman CLA 2008-04-11 10:27:49 EDT
Thanks for the clarification. The work-around does seem to work appropriately.
Comment 5 Andrew Clement CLA 2008-04-21 13:02:05 EDT
Created attachment 96891 [details]
Workspace patch (tests/weaver) - fixes this bug
Comment 6 Andrew Clement CLA 2008-04-24 00:31:08 EDT
Fixes committed - they will be in the next dev build and in AspectJ1.6.1