[aspectj-users] Aspect works despite "ambiguous binding" error

["Alexander Kriegisch" <alexander@xxxxxxxxxxxxxx>]

I just encountered a strange case in which I get a compiler error (really an error, not a warning according to Eclipse), but the aspect is compiled anyway and runs just fine:

class A {
	public void foo(String text, int number) {}
	public void bar(int number, Object object, String text) {}

	public static void main(String args[]) {
		new A().foo("xxx", 11);
		new A().bar(11, 3.14, "bbb");
	}
}

public aspect AmbiguousBindingAspect {
	before(String text) :
		execution(* A.*(..)) && args(text, ..) ||
		execution(void *(..)) && args(.., text)
	{
		System.out.println(thisJoinPoint + " -> " + text);
	}
}

Console output:
execution(void A.foo(String, int)) -> xxx
execution(void A.bar(int, Object, String)) -> bbb

I know that this might be better as a Bugzilla ticket than a question here, but maybe somebody can tell me if this is somehow expected behaviour or an improvement for statically disambiguating parameter bindings has been implemented, but the error not removwed from Ajc or whatever. BTW, it makes no difference whether the aspect is in native syntax of @AspectJ style. But there is a second problem when mixing styles like this:

public aspect AmbiguousBindingAspect {
	@Before("(execution(* A.*(..)) && args(text, ..) || execution(void *(..)) && args(.., text)) && !execution(* *())")
	public void advice2(JoinPoint thisJoinPoint, String text) {
		System.out.println(thisJoinPoint + " -> " + text);
	}
}

Exception in thread "main" java.lang.VerifyError: Bad type on operand stack
Exception Details:
  Location:
    A.foo(Ljava/lang/String;I)V @27: invokevirtual
  Reason:
    Type 'org/aspectj/lang/JoinPoint' (current frame, stack[2]) is not assignable to 'java/lang/String'
  Current Frame:
    bci: @27
    flags: { }
    locals: { 'A', 'java/lang/String', integer, 'java/lang/String', 'org/aspectj/lang/JoinPoint', integer }
    stack: { 'AmbiguousBindingAspect', 'java/lang/String', 'org/aspectj/lang/JoinPoint' }
  Bytecode:
    0000000: 2b4e 1c36 05b2 0058 2a2a 2d15 05b8 005d
    0000010: b800 603a 04b8 0065 2d19 04b6 0069 b1  

	at java.lang.Class.getDeclaredMethods0(Native Method)
	at java.lang.Class.privateGetDeclaredMethods(Unknown Source)
	at java.lang.Class.getMethod0(Unknown Source)
	at java.lang.Class.getMethod(Unknown Source)
	at sun.launcher.LauncherHelper.getMainMethod(Unknown Source)
	at sun.launcher.LauncherHelper.checkAndLoadMain(Unknown Source)

I thought this had been fixed already, but maybe it is another corner case.
-- 
Alexander Kriegisch
http://scrum-master.de