Community
Participate
Working Groups
Currently it is possible to match on parameter annotations: execution(* *(@SomeAnno (*),..)) but you cannot bind them directly in the syntax. You are forced to write some nasty code to go digging for them on the method that matches. I'm thinking about this new possibility: before(SomeAnno anno): execution(* *(..)) && @args(anno (*)) {} the extra parentheses in @args do the same as in the execution syntax, enabling the annotation to be treated as on the parameter rather than on the type of the parameter. // binding the type annotation and the param annotation before(SomeAnno anno,TypeAnno anno2): execution(* *(..)) && @args(anno (anno2)) {}
Hi Andy. I think this feature is something people have been waiting for since AspectJ 1.6.0, see for example: http://stackoverflow.com/a/38802836/1082681 http://stackoverflow.com/a/16624766/1082681 http://stackoverflow.com/a/23952001/1082681 Do you have any plans to implement this soon? Please consider this as an upvote. ;-)
I'll take a closer look when I get a minute. I really appreciate you providing feedback - I know you jump on the stackoverflow questions for AspectJ and providing feedback through bugzilla to me on how I can help those users is great. The Java9 upgrade is messier than I thought/hoped so that will take a bunch of cycles. On an unrelated note - but also perhaps on the TODO list - I've been thinking/experimenting with weaving lambda generated methods so that I can catch calls/executions of methods being supplied by lambdas (eg. Runnable.run(..)) rather than anonymous inner classes.
I started some work on this it is in the paramAnnotationBinding branch in git. It is much more involved than I initially anticipated and perhaps most importantly requires a change to the serialized form of the aspect. When this happens you usually trigger a chain of bug reports where people are using an old weaver with a new compiler. When these changes occur you need to use the newest weaver if you are using the newest compiler. For that reason I might wait and resurrect this for 1.9 rather than trying to get it into 1.8.10. it is currently working with the proposed syntax (some testcases are passing).
For me personally that would not be a problem, I always try using the latest compiler and weaver anyway. I do understand that it would not make life easier for less experienced users, though, especially when using AspectJ Maven plugin and being unaware of the possibility (and necessity, in this case) to override the plugin's dependencies. Whenever this will become part of an actual AspectJ release, I would be willing to test a snapshot if you can provide binaries. (I am kind of reluctant to build AspectJ myself because I do not like or understand Ant, being a Maven user.) Thank you, Andy.
