Community
Participate
Working Groups
Using @AJ style declare error/warnings within a package and the pointcut is of the type: execution(* C.warningMethod()) then a 'no match for this type name: C [Xlint:invalidAbsoluteTypeName]' warning is thrown. This, however, matches if you write the aspect in code style. Moreover, this matches when in @AJ style and in the default package.
Created attachment 34190 [details] testcase patch Patch containing failing testcase. Apply to the tests project.
The problem is occuring because when the bindings for the declaring type of the following signature * C.warningMethod() are being resolved, the logic is using "C" rather than "pkg.C". Therefore, when the signature LC is looked for it doesn't exist. In the case of code style aspect, the signature which is looked for is Lpkg/C which does exist. The difference between the two mechansims is the IScope they use. The @AJ style mechanism uses AtAjAttributes.BindingScope which is an extension of SimpleScope. The code style mechanism uses EclipseScope.
Types in annotations in general have to be fully qualified since there is no notion of "imports" in a .class file. However, in the case of types in the same package as the type declaring the annotation, we should build a scope that "imports" the package as a convenience for this common case. This is very straightforward to do (and many of the existing test cases already do something similar).
Created attachment 34265 [details] zip containing patches The attached zip file contains three patches: * pr126560-tests-patch3.txt - apply to the tests project. This contains the previous testcase patch, plus two extra tests * pr126560-weaver-patch2.txt - apply to the weaver project. This contains part of the proposed fix. * pr126560-org-aspectj-ajdt-core-patch.txt - apply to the org.aspectj.ajdt.core project. This contains part of the proposed fix. This bug has two parts: 1. When the @AJ aspect and class it's affecting are in the same package 2. When the @AJ aspect and class it's affecting are in different packages and the other package has been added as an import The fix for these two are slightly different. The fix I've proposed for (1) is to add an implementation of lookupType(String, IHasPosition) in AtAjAttributes.BindingScope. This implementation adds the package in which the declaring aspect is to the list of imported prefixes declared in the super class SimpleScope (previously this was just "java.lang.") and then calls the implementation in SimpleScope. To fix (2) you need to get hold of the import statements and then augment the AtAjAttributes.BindingScope.lookupType(String, IHasPosition) implementation to add these imports to the list of imported names declared in the super class SimpleScope. To do this, I added getter and setter methods against org.aspectj.weaver.ResolvedType and then set these in the constructor of org.aspectj.ajdt.internal.compiler.lookup.EclipseSourceType. The reason I've done this here is that within EclipseSourceType you have the CompilationUnitDeclaration on which you can ask for the imports. Then, in AtAjAttributes.BindingScope.lookupType(String,IHasPosition) you can use the enclosing type to get hold of these imports, just as you use it in the fix for (1) to get hold of the package name. This also required ammending slightly the implementaiton of SimpleScope.lookupType(String,IHasPosition) to check whether ".name" was at the end of the given import name rather than "name" (otherwise org.aspectj.lang.JoinPoint was matching int). It's a bit messy manipulating arrays and lists of strings, plus I wasn't sure whether or not to ignore imports that start org.aspectj.lang.
I had a think about this on my run. I think the fix for part 1 is fine and we'll put that in - when the affected type is in the same package as the aspect containing the unqualified reference. For part 2, I don't think we can do it as intended in the fix. As Adrian says, there is no notion of what the imports were in the class file, and Helens very cunning fix gets around this by stashing the imports from compilation against the resolvedtype and then retrieving them later when weaving. This works but doesn't allow for the primary intent for @AJ aspects - that they are compilable with javac and then usable for binary weaving or LTW. If we used source knowledge like this, we'd have an aspect that compiles and weaves fine under ajc - but if built with javac would give no errors and then fail to match during binary weaving or load time weaving as the type can't be resolved. I'm also nervous about storing data in the resolvedtype object that didn't come from the bytecode as its possible these resolvedtype objects may come and go with our memory changes. What I'd rather do is force either explicit qualification of the type (kind of what we are doing now with the error message) OR (and this is something I'm sure we've talked about before??? i even thought we'd implemented???) have an @Imports annotation or 'namespace' value on the @Aspect annotation - this would specify the namespace in which to resolve unqualified entries. It would then be explicit in the source and captured in the classfile and thus usable when binary weaving or LTW....
I've reworked the patch and applied the bit I intended to which supported resolution of types in the same package as the aspect/pointcuts. Seems to work fine! I had to remove one of the tests and some of the infrastructure from the patch that remembered the imports from compile time through weave time... To address the other part, we may need to look at @Imports()
moving to an enhancement
