I also think that it would be fine if we apply no arguments null to b/a/t/f. If we don't apply the same policy, it would make a difference. Look at this: | public void before(@Args Object arguments) | { | ... | } | | public Object around(Invocation invocation) throws Throwable | { | ... | } | Suppose both advices are applied to a POJO->method() execution joinpoint: | public class POJO | { | public void method() | { | ... | } | } | If we apply different policies to before and around, i.e.: - keep null @Args only for FieldRead (current policy), which means "before" advice would receive a non-null array in the example above - Invocation needs to contain a null array because the arguments length is 0 We would need to change JoinPointGenerator because it currently copies arguments array used on before advice to the invocation that will be passed as parameter to "around" advice, and this would break the null args invocation policy. This is just an example. But it illustrates how interaction between b/a/t/f and around makes a difference when there are no arguments, if we use different null policies. Nonetheless, I can also implement different policies on both, if that is the case. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4031593#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...