Community
Participate
Working Groups
The crosscutting model is not being correctly udpated after an incremental build. To reproduce: 1. Import attached project 2. Open AnAspect.aj 3. Change AClass.xxxx to f.AClass.xxxx (fully qualified name) 4. Save 5. Gutter marker disappears 6. Full build 7. Gutter marker reappears Same thing happens with the ITD method and ITD constructor.
Created attachment 139245 [details] Project that exhibits this behavior
I think this bug is more problematic than just the model being affected. During the incremental build (at least for me) there is a compilation error saying that f and f.AClass cannot be found. I believe the cause to be related to bug 269562. Under that bug the name environment is being reset too frequently. What that means here is that when the aspect is rebuilt on the incremental compile we have already forgotten about the package 'f'. I think fixing 269652 will cause this to also be fixed. But I don't plan on fixing that for 1.6.5 - it is a bit disruptive.
Now that 269652 is fixed, I've gone back to this bug and it isn't magically addressed by that fix unfortunately. The observation I have between the full and incremental builds is that on the incremental build, the entry in the model for the ITD changes from: =IncrBuilds/src<g*AnAspect.aj}AnAspect)AClass.xxxx to =IncrBuilds/src<g*AnAspect.aj}AnAspect)f.AClass.xxxx whilst the relationship does not change: =IncrBuilds/src<g*AnAspect.aj}AnAspect)AClass.xxxx :: =IncrBuilds/src<g*AnAspect.aj}AnAspect)AClass.xxxx --declared on--> [=IncrBuilds/src<f{AClass.java[AClass] =IncrBuilds/src<f{AClass.java[AClass :: =IncrBuilds/src<f{AClass.java[AClass --aspect declarations--> [=IncrBuilds/src<g*AnAspect.aj}AnAspect)AClass.xxxx So after the incremental build there is an inconsistency, the 'f.' part is missing from the relationship that was added to the model. My question for Andrew would be which is correct? Should the model element have changed handle to include the f. type qualification (in which case the relationship is wrong) or should the relationship have been updated to include the f. type qualification?
I would like to have seen the relationship be updated to include the fully qualified name. In general, I would expect that the handles mimic what is in the source code. So, if something is fully qualified in the source, then its handle should be fully qualified as well. As a side note, this breaks down when looking at binary code. Here, because there is no source to fall back on, I'd expect to see all places fully qualified where possible.
thanks. i plan on addressing the case here, source, and not binaries - if that needs fixing it needs a separate bug.
> I would like to have seen the relationship be updated to include the fully > qualified name. Unfortunately... you can't have that. After investigating further, whether the name was fully qualified in the original declaration is not persisted as part of the state for an ITD. To persist this extra information would require me to change the binary form of the attributes for all ITDs and I don't want to do that right now for something like this. It would also mean that on changing between unqualified and fully qualified (when they end up pointing at the same type) we would need to do big incremental builds that involved the aspect and all affected targets. If the rule is simply that any qualification of the type is ignored in the handles then it can be a fast incremental build of just the aspect when this change is made. So, for now, I have removed 'f.' from the handles and it all works just fine.
OK. That's reasonable, I think. Could get us into trouble in the odd situation where; import foo.MyClass; import bar.MyClass; aspect A { int foo.MyClass.x = 9; int bar.MyClass.x = 9; } but this seems rare enough that we can handle it only when it comes up.
believe enough has been done for now.
