Community
Participate
Working Groups
In the current 20050202 build, type resolution seems to be broken: The attached project gives the error "ConstantArguments cannot be resolved" although the class resides in the same package as the importing aspect. Even full qualification and an (actually unnecessary import) do not work.
Created attachment 17640 [details] Eclipse project producing the error
Hmmm. The failing code looks like this from the ConstantArgumentsAspect around advice: Object around(): constantArgumentMethods() { Signature sig = thisJoinPointStaticPart.getSignature(); Class c = sig.getDeclaringType(); MethodSignature msig = (MethodSignature)thisJoinPointStaticPart.getSignature(); Method m = c.getMethod(sig.getName(), msig.getParameterTypes()); ConstantArguments = (ConstantArguments) m.getAnnotation(ConstantArguments.class); Shouldn't that last line read: ConstantArguments annotation = (ConstantArguments) m.getAnnotation(ConstantArguments.class); The message is refering to the fact that ConstantArguments is not defined as a field.
(In reply to comment #2) > Shouldn't that last line read: > > ConstantArguments annotation = > (ConstantArguments) m.getAnnotation(ConstantArguments.class); Ah, oh course you are right. Anyway in that case I find the error message really missleading because it should say something like "identifier expected" rather than "ConstantArguments cannot be resonved".
more parser fun for aj5m3...
We behave in exactly the same way as the Eclipse 3.1 JDT compiler on this program. It's not around advice related. The program: public class PoorErrorMessage { void aMethod() { Foo = getFoo(); // note missing identifier } Foo getFoo() { return null; } } class Foo {} gives the same message "Foo cannot be resolved". I think this is a reasonable message for the compiler to issue, the statement is a well-formed Java statement assigning the result of a call to getFoo to a variable called "Foo". Since there is no variable "Foo" in scope, you get the resulting message. The only point of confusion here is that you used a type name as the "variable" name - but I still contend the message is reasonable. You could raise a JDT bug if you disagree, and if they fix it we will pick up that fix in a future version of AspectJ
