Community
Participate
Working Groups
Compiling the following aspect -------------------------------------------------------------------------- package pkg; public aspect A { before() : execution(* pack.C.method1()) && this(pack.C) { System.out.println("before exec method1 and this is C"); } before() : call(* pack.C.method2()) && target(pack.C) { System.out.println("before call to method2 and target is C"); } } ------------------------------------------------------------------------- and placing the resultant class file on the aspectpath for a project containing the following class ------------------------------------------------------------------ package pack; public class C { public C() { } public void method1() { new C().method2(); } public void method2() { } public static void main(String[] args) { new C().method1(); } } ------------------------------------------------------------------ results in no weaving taking place unless the compiled class C is put on the build path when the aspect is built. Removing the 'this' and 'target' from the pointcuts everything works as expected (weaving takes place regardless of whether C is put on the build path when the aspect is built). Note the same behaviour occurred on 1.2.1.
this bug is what I suspected. During the initial build of the aspect, the type pattern in this or target (which must be an exact type pattern) is resolved to NoTypePattern (because the type cannot be found). It is then serialized as NoTypePattern and later deserialized for the secondary compile as a NoTypePattern - this matches nothing ... Should probably serialize the pre-resolved form. I dont think this affect incremental compilation as it is only an issue if the type pattern cannot be resolved in a world. In the world behind incremental compilation of a project, the type *will* exist and everything will work fine.
of course...this will be currently affecting *all* pointcuts that get a fully specified type pattern (some require it eg. this/target whilst in others it can either by fully specified or a pattern). it is a serious change to switch how we are working here because we assume all deserialized pointcuts are fully (correctly) resolved. So I dont think this should be done for 1.5.2
i turned helens code into a testcase - the expected output isnt correct but the basics are there, its commented out in Ajc152tests...
restriction that we ought to look at resolving for 1.6.0 - surely we can serialize in some other form?
unsetting the target field which is currently set for something already released
