Community
Participate
Working Groups
The proposal is to split the matching and weaving process. Although the pointcut matching is already usable as a standalone entity, it cannot currently be used without also having the weaving code around (and so the entirety of aspectjweaver.jar is required). Also, when the matching is used standalone it still attempts to access the information necessary to determine a match through reflection. It would be better if that were pluggable (perhaps an abstraction over the required information) and then the user could embed it wherever they wish and provide that information however suits their environment. Two use cases need supporting: - matcher code can be used without the weaver code (without org.aspectj.weaver.bcel.*). So that a user may have a matcher without 'worrying' that bytecode may get altered. - matcher code can be backed by an Eclipse JDT model of resources rather than reflection This second case will enable much neater matching in Eclipse and even sets up the possibility of showing matches *as you type*
first pass is complete in AspectJ 1.6.3