Summary: | [generics] Reference to pointcut defined in generic aspect, within generic interface | ||||||
---|---|---|---|---|---|---|---|
Product: | [Tools] AspectJ | Reporter: | Paulo Zenida <Paulo.Zenida> | ||||
Component: | Compiler | Assignee: | aspectj inbox <aspectj-inbox> | ||||
Status: | RESOLVED FIXED | QA Contact: | |||||
Severity: | major | ||||||
Priority: | P2 | ||||||
Version: | DEVELOPMENT | ||||||
Target Milestone: | 1.5.3 | ||||||
Hardware: | PC | ||||||
OS: | Windows XP | ||||||
Whiteboard: | |||||||
Attachments: |
|
Description
Paulo Zenida
2006-09-03 10:16:33 EDT
I can reproduce the problem with the (excellent) testcase. Moving MyAspect1<T> into it's own source file avoids the exception which makes me think it might be related to Bug 153490 "IllegalStateException thrown: ...". Will need to do some more investigation. From the error message "IllegalStateException thrown: Expecting raw type" it is possible this bug is related to bug 152848. After some initial investigation I don't believe this bug is related to bug 152848. The problem here is to do with being an inner type. Converting the supplied testcode into a testcase that fits within the testsuite, the latest code from HEAD returns the following message: Expecting raw type, not: MyInterface$MyAspect1<> What's happening is that we're entering TypeFactory.createParameterizedType(..) with a ResolvedType that isn't a generic type (which is why we go on to find the generic type) but is a parameterized type. Therefore, the test isRawType() returns false and we blow up with the IllegalStateException. Created attachment 49475 [details]
failing testcase
Apply this patch to the tests project.
I think I can say with some confidence that we have *no* tests for generic inner aspects of generic types. That program looks scary to me but it is highlighting a few bugs. Behind the failures there are actually problems with the pointcut: within() can't take a parameterized type - there would be no difference between within(Foo<String>) and within(Foo<Integer>) - there is only one Foo. So I will working on fixing this bug but I have to warn you that this could well be a buggy area and some bugs may not get fast turnaround, since I think I can see some infrastructure missing from our implementation that needs writing to handle these situations. alright, i have fixed this. Or rather I've selotaped over this particularly bug. It is still not a well tested area and I've added just two tests for this scenario - so I expect to see related bugs in the future... fixes are available in aj dev builds |