Community
Participate
Working Groups
I get no error when around advice returns a parameterized type and the pointcut picks out a join point which does not return that type. In this code, the around advise runs without error (the result is ignored), but there should be a compile-time error. -------------------------------------------------------------------- public class ConstructorResult { public static void main(String[] args) { test(); } public static void test() { new C(); } static class C { static int COUNT; final int count = ++COUNT; C() { System.out.println("c: " + count); } } // properly get compiler error wrt return type of join point // static aspect Normal { // C around() : execution(C.new()) { // return proceed(); // } // } // no compiler error wrt return type of join point static abstract aspect SS<Target> { abstract protected pointcut creation(); Target around() : creation() { // expect CE for execution(C.new()); return proceed(); } } static aspect A extends SS<C> { protected pointcut creation() : execution(C.new()); } }
What a nightmare!! I've fixed it, but worth keeping a list of what I changed and why: we have members like 'getDeclaredMethods()' in ResolvedType - when these are called for a parameterized form of a generic type, the return value (the set of methods) are parameterized forms of the generic methods according to the type parameters used in the parameterized type. We also have a method 'getDeclaredAdvice()' which was partially transforming the advice it was returning but it didnt modify the signature of the advice from the generic type - in the case of this bug, this meant the return value of the advice 'Target' was collapsed to a bound rather than set to the type parameter for the subtype 'C'. I modified the parameterization logic to work for advice members too. Basically I changed the 'ShadowMunger.parameterizeWith()' method to take an extra parameter (the parameterized type) so that the signature for the munger could be modified. You then get the error reported as expected by Wes. However, I then wrote a test program that was allowed to be advised by this kind of parameterized advice. Unfortunately my parameterization changes meant that when we reached the weaving of the advice we were incorrectly using the parameterized signature in trying to work out what to call in the code we generate - so I had to modify the code generation to use the original generic signature and include the appropriate casts. This was easy because whenever we parameterize a member we stash the original member in the parameterized variant we construct - hence all the new references to 'hasBackingGenericMember()'. So, the changes: ResolvedMemberImpl.parameterizedWith() - had to fix it to copy the parameternames across when returning a parameterized member backed by a generic member. ShadowMunger.parameterizeWith() - added the parameterized type as a field to the method. ResolvedType.getDeclaredAdvice() - calls the new form of parameterizeWith() on the mungers. Checker - had to implement the new form of parameterizeWith() Advice.getDeclaringAspect() - changed to allow for parameterized advice inherited from generic aspects. BcelAdvice.parameterizeWith() - parameterizes the signature of the munger too. Utility.createInvoke() - no longer tries to create invokeStatic calls to parameterized types! BcelShadow - changed so that code gen copes with parameterized advice. and with all that - it works. fix checked in.
fix available.
