Summary: | effect of an after returning type incompatible with a join point return type | ||
---|---|---|---|
Product: | [Tools] AspectJ | Reporter: | Wes Isberg <wes> |
Component: | Compiler | Assignee: | Erik Hilsdale <eh-ajdev> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | P2 | CC: | jim-aj |
Version: | 1.1.0 | ||
Target Milestone: | 1.2 | ||
Hardware: | PC | ||
OS: | Windows NT | ||
Whiteboard: |
Description
Wes Isberg
2003-09-06 19:18:07 EDT
I'm moving this to be a doc bug after discussing the issue with Erik. We decided in 1.1.1 to make the matching rules for after returning(C c) to be based on instanceof matching in the same way that after throwing is. We decided that having these two constructs behave in a parallel way was more important than the additional benefits of static type checking people would get otherwise. There should probably be a Xlint warning to let people know when after returning advice either might not or definately will not run at a particular join point shadow based on the additional matching done by the type in returning. Oops, I should have said "we decided in the design of 1.1" rather than "1.1.1". This decision was made about a year ago when we first implemented bytecode weaving. After exploring this bug I've written a comprehensive test case tests/new/AfterReturningParamMatching.java however, this test case exposed a compiler blowup when after() returning(byte b) is applied to an Object returning jp. I've rewritten the semantics document to reflect the correct (instanceof-like) semantics, checked the above test case into ajcTestsFailing.xml, moved this bug back to the compiler and raised its severity to P2. I'm still owner, and will fix it when I get the chance. -erik The proper semantics for after returning parameter exposure should now be implemented, and the test case has been moved into ajcTests. |