Summary: | Inter-type declaration with generic return type across packages causes return type incompatibility | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Tools] AspectJ | Reporter: | Michael Huffman <mhuffman> | ||||||
Component: | Compiler | Assignee: | AJDT-inbox <AJDT-inbox> | ||||||
Status: | RESOLVED FIXED | QA Contact: | |||||||
Severity: | critical | ||||||||
Priority: | P2 | CC: | aclement, mhuffman, vb | ||||||
Version: | DEVELOPMENT | ||||||||
Target Milestone: | 1.6.1 | ||||||||
Hardware: | PC | ||||||||
OS: | Windows XP | ||||||||
Whiteboard: | |||||||||
Attachments: |
|
Description
Michael Huffman
2008-04-10 13:01:28 EDT
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 |