Description Steve Ash 2011-12-05 10:55:14 EST

There have been a number of cases where I have wanted to create general purpose aspects to add in particular behavior.  In our environment, requiring developers to understand aspectJ pointcut syntax has not worked out well.  Instead we have a few developers that understand it and create "general purpose" aspects that are usually weaved in by using annotations which are used in pointcuts.  For example, we have an @Trace pointcut which will trace method invocations if the annotation is targeting at a method, and will trace all public method invocations if targeting a type.

We would like to use some aspects to help us do some better defensive coding.  One such aspect that has been identified would be something like @CantCallFromSubclass.  This annotation would target a method, and the hope would be that if any method in a subclass called it the "declare" advice would emit a compiler error.  We would also like a symmetric @MustCallFromSubclass.

So for a code example of the use case:


 public class SuperClass {
    public final void dontCallThisFromBase() { }
 }

 public class BaseClass extends SuperClass {
    public void doSomething() {
       super.dontCallThisFromBase(); // would love to be a compiler error
    }
 }

 public class UnrelatedClass {
    public void unrelatedMethod() {
       new SuperClass().dontCallThisFromBase(); // this is ok
    }
 }

Per the gracious people on the users mailing list we were given this suggestion for a pointcut:

within(SuperClass+) && !within(SuperClass) && call(@CantCallFromSubclass * SuperClass.*())

And this works, but we are then left to create one of these (or perhaps some abstract -> concrete aspect refactoring) for each type hierarchy that we want to target.

A nice extension to the aspectJ annotation support might be a TypePattern that allowed one to specify "any type which contains a method annotated with".  Currently, we can target types annotated with a certain annotation and methods annotated with a certain annotation but not types _containing_ methods annotated with a certain annotation.  And this is a common idiom: Spring's @Transactional, @Trace, etc. are all typically method level annotations.  It might be nice to be able to weave in things at construction time or static initialization time based on usages of this idiom.  Currently, one must resort to concrete aspects for each, or adding an additional annotation to each class, which is fragile.