Community
Participate
Working Groups
the traditional Java-ish analysis done whilst preparing for an incremental build will work for AspectJ. But some scenarios happen in an AspectJ world that could be recognized earlier and lead to more optimal incremental builds. For example. An ITD from type A targets some type C. If C is changed, it gets built, then we notice that C was depended upon by A, so we do another compile including A and C. Now, type C is probably 99% of the time still going to be affected by the ITDs from type A. So it would be slightly more optimal to have done the build of A and C together in the first place - i think. This is at least worth benchmarking to see if would make a difference if the first compile could be eliminated.
take a look for 1.6.4
Another optimization relates to minimizing the amount of duplicate work done when applying ITDs. When developing an interface implementation and applying it via ITDs, typically there will be a set of ITDs together that all target the same type: public void Target.method1() {} public void Target.method2() {} public void Target.method3() {} Currently there is no shared knowledge amongst these ITDs, so for every type we come across we analyse it three separate times as to whether it is a target for each method. Since the targets are identical we could do the analysis once and share that knowledge amongst the other similar ITDs. In the interface case, where we are discovering the topmost implementing class (which will get the method bodies applied), this can be quite an expensive calculation that we could avoid repeating.
Created attachment 123108 [details] Patch for sharing target type analysis info between ITDs First pass at the shared analysis feature. Appears to behave but I haven't quite thought through: - lifecycle of the analysis info, when does it get tidied up safely? - how do declare parents damage the analysis info? Does it become stale?
unsetting the target field which is currently set for something already released
