Bug 148381 - [@AspectJ] Bindings through argNames doesn't seem to work
Summary: [@AspectJ] Bindings through argNames doesn't seem to work
Status: RESOLVED FIXED
Alias: None
Product: AspectJ
Classification: Tools
Component: Compiler (show other bugs)
Version: DEVELOPMENT   Edit
Hardware: PC Windows XP
: P3 normal with 1 vote (vote)
Target Milestone: 1.5.4   Edit
Assignee: aspectj inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-06-23 08:56 EDT by Ramnivas Laddad CLA
Modified: 2007-11-08 10:42 EST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ramnivas Laddad CLA 2006-06-23 08:56:51 EDT
I have a simple aspect with bound arguments to advice. It all works fine with 'ajc' as the compiler or with 'javac -g', but not when I try with argNames and 'javac' without -g.

Here is the aspect:
package test;

import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.annotation.Around;
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Pointcut;

@Aspect
class Monitor {
	@Pointcut(value="execution(@PerformanceMonitor * *(..)) && @annotation(monitoringAnnot)", argNames="monitoringAnnot")
	public void monitored(PerformanceMonitor monitoringAnnot) {}
	
	@Around(value="monitored(monitoringAnnot)", argNames="pjp, monitoringAnnot")
	public Object flagExpectationMismatch(ProceedingJoinPoint pjp, PerformanceMonitor monitoringAnnot) throws Throwable {
		long start = System.nanoTime();
		Object ret = pjp.proceed();
		long end = System.nanoTime();
		
		if(end - start > monitoringAnnot.expected()) {
			System.out.println("Method " + pjp.getSignature().toShortString() + " took longer than expected\n\t"
					+ "Max expected = " + monitoringAnnot.expected() + ", actual = " + (end-start));
		}
		return ret;
	}	
}

And here is a class:
package test;

import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

public class Main {
	public static void main(String[] args) {
		new Main().foo();
	}
	
	@PerformanceMonitor(expected=1000)
	public void foo() {
		
	}
}

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
@interface PerformanceMonitor {
	public int expected();
}

And here is META-INF/aop.xml:
<aspectj>
    <aspects>
         <aspect name="test.Monitor"/> 
    </aspects>
</aspectj>

> ajc -source 1.5 test\*.java
> java test.Main
... normal

> javac -g:vars test\Monitor.java
> javac test\Main.java
> java -javaagent:%ASPECTJ_LIB_HOME%\aspectjweaver.jar test.Main
... normal

> javac test\*.java
> java -javaagent:%ASPECTJ_LIB_HOME%\aspectjweaver.jar test.Main
error at <Unknown>::0 Cannot read debug info for @Aspect to handle formal bindin
g in pointcuts (please compile with 'javac -g' or '<javac debug='true'.../>' in
Ant)
warning register definition failed
Comment 1 Andrew Clement CLA 2006-06-23 09:10:10 EDT
Errr - isnt the clue in the error message?

error at <Unknown>::0 Cannot read debug info for @Aspect to handle formal binding in pointcuts (please compile with 'javac -g' or '<javac debug='true'.../>' in Ant)
warning register definition failed

If the debug information isn't in the class file (ie. the parameter/localvar names) then at weave time we don't have any idea which parameters line up with which 'names' from the pointcut...

this is a known limitation for argument binding in @AJ style - or am I not quite understanding what you are reporting?  We can't influence what javac puts in the class file without -g, I suppose in some situations a 'lucky guess' based on the type of the arguments and the type of the value in the pointcut could be performed but that's highly unstable...
Comment 2 Ramnivas Laddad CLA 2006-06-23 09:35:08 EDT
I am reporting that if I use 'argNames' property in pointcuts and advice, I should *not* need '-g' or '-g:vars'. There seems to be no documentation of this property (except Adrian's blog and some Spring documentation) and I suspect this feature may not have been exercised much!
Comment 3 Andrew Clement CLA 2006-06-23 09:40:37 EDT
Doh! of course, ignore me Ramnivas, I'm being stupid.  I completely forgot we had that feature ... so that probably does suggest it has had minimal testing ;)
Comment 4 Andrew Clement CLA 2007-11-08 07:35:37 EST
In addition to minimal testing, there is minimal implementation ... there is no support for it in the codebase and I'm just adding it now, together with a number of tests.
Comment 5 Andrew Clement CLA 2007-11-08 10:42:21 EST
Basic tests are in, as well as the full feature implementation.  I've tested some simple error scenarios but no doubt could have done more - i'll fix it up further if problems occur in the field.