Community
Participate
Working Groups
Build Identifier: 20090920-1017 Consider simple class: public class Work { @Idempotent public Object work() throws Exception { Thread.sleep(100); return new Object(); } } The test: public class SmartAspectBugTest { @Test public void test() throws Exception { new Work().work(); } } And the aspect: public aspect SmartAspect { @Around("execution(@Idempotent * *(..))") public Object aroundIdempotentMethod(ProceedingJoinPoint pjp) { return null; } } Test run produces: java.lang.VerifyError: (class: eg/Work, method: work signature: ()Ljava/lang/Object;) Incompatible argument to function at eg.SmartAspectBugTest.test(SmartAspectBugTest.java:9) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) ... It's definitely a bug 'cause an "old style"(w/o @AspectJ) works. Thanks for your time! Reproducible: Always Steps to Reproduce: Run test defined above. Environment: Java 1.5.0_17, org.aspectj.runtime_1.6.6.20090930185500
looks like the joinpoint returned from the injected makeJP call is not checkcast'd to ProceedingJoinPoint. However, I am a bit confused as this looks like such a simple case (confirmed to fail in 1.6.8 too)
the reason this doesn't come up all the time, is because it is actually mixing the styles. The aspect is code style whilst the advice is annotation style. Switching it to an annotation style aspect causes it to work just fine. The parameter setup code for inlined around advice (where this problem manifests) is well overdue a rewrite rather than yet another hack on top of what is already there, I think I might tackle that rewrite under this bug.
unsetting the target field which is currently set for something already released