Community
Participate
Working Groups
In the section Appendix B -> Static crosscutting -> Conflicts of the Programming Guide there is some sample code given on use of ITDs to add a field and method to every type in a named Java package ... <snip> aspect A { private Registry otherPackage.*.r; public void otherPackage.*.register(Registry r) { r.register(this); this.r = r; } } </snip> This code is no longer valid as use of wildcarding in ITD definitions was obsoleted in the 1.1 release. Suggest it be replaced with a code fragment that introduces the field and method on an interface that every type in the named package implements.
The new text... Inter-type declarations raise the possibility of conflicts among locally declared members and inter-type members. For example, assuming otherPackage is not the package containing the aspect A, the code aspect A { private Registry otherPackage.onType.r; public void otherPackage.onType.register(Registry r) { r.register(this); this.r = r; } } declares that onType in otherPackage has a field r. This field, however, is only accessible from the code inside of aspect A. The aspect also declares that onType has a method "register", but makes this method accessible from everywhere. If onType already defines a private or package-protected field "r", there is no conflict: The aspect cannot see such a field, and no code in otherPackage can see the inter-type "r". If onType defines a public field "r", there is a conflict: The expression this.r = r is an error, since it is ambiguous whether the private inter-type "r" or the public locally-defined "r" should be used. If onType defines a method "register(Registry)" there is a conflict, since it would be ambiguous to any code that could see such a defined method which "register(Registry)" method was applicable. Conflicts are resolved as much as possible as per Java's conflict resolution rules: A subclass can inherit multiple fields from its superclasses, all with the same name and type. However, it is an error to have an ambiguous reference to a field. A subclass can only inherit multiple methods with the same name and argument types from its superclasses if only zero or one of them is concrete (i.e., all but one is abstract, or all are abstract).
Now updated in CVS tree and on AspectJ website.
Fix released as part of AspectJ 1.2.1
