Community
Participate
Working Groups
java.lang.NullPointerException at org.aspectj.weaver.bcel.BcelShadow.weaveAroundInline(BcelShadow.java:2109) at org.aspectj.weaver.bcel.BcelAdvice.implementOn(BcelAdvice.java:232) at org.aspectj.weaver.Shadow.implementMungers(Shadow.java:639) at org.aspectj.weaver.Shadow.implement(Shadow.java:456) at org.aspectj.weaver.bcel.BcelClassWeaver.implement(BcelClassWeaver.java:2236) at org.aspectj.weaver.bcel.BcelClassWeaver.weave(BcelClassWeaver.java:491) at org.aspectj.weaver.bcel.BcelClassWeaver.weave(BcelClassWeaver.java:109) at org.aspectj.weaver.bcel.BcelWeaver.weave(BcelWeaver.java:1560) at org.aspectj.weaver.bcel.BcelWeaver.weaveWithoutDump(BcelWeaver.java:1511) at org.aspectj.weaver.bcel.BcelWeaver.weaveAndNotify(BcelWeaver.java:1291) at org.aspectj.weaver.bcel.BcelWeaver.weave(BcelWeaver.java:1113) at org.aspectj.ajdt.internal.compiler.AjCompilerAdapter.weave(AjCompilerAdapter.java:311) at org.aspectj.ajdt.internal.compiler.AjCompilerAdapter.afterCompiling(AjCompilerAdapter.java:183) at org.aspectj.ajdt.internal.compiler.CompilerAdapter.ajc$afterReturning$org_aspectj_ajdt_internal_compiler_CompilerAdapter$2$f9cc9ca0(CompilerAdapter.aj:70) at org.aspectj.org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:367) at org.aspectj.ajdt.internal.core.builder.AjBuildManager.performCompilation(AjBuildManager.java:862) at org.aspectj.ajdt.internal.core.builder.AjBuildManager.doBuild(AjBuildManager.java:242) at org.aspectj.ajdt.internal.core.builder.AjBuildManager.batchBuild(AjBuildManager.java:161) at org.aspectj.ajde.internal.CompilerAdapter.compile(CompilerAdapter.java:122) at org.aspectj.ajde.internal.AspectJBuildManager$CompilerThread.run(AspectJBuildManager.java:191)
Passing over to the compiler. Please can you add your exact AJDT and AspectJ version numbers.
org.aspectj.weaver_1.5.0.20060405045058 org.eclipse.aspectj_1.3.1.20060405045058
*** Bug 135213 has been marked as a duplicate of this bug. ***
Antti, can you possibly try something for me on your scenario that might help me narrow things down? Can you remove the -XnoInline workaround I asked you to use and instead try '-Xset:activateLightweightDelegates=false' - does it still fail? thanks.
Also Antti, can you tell me if your aspects are compiled from source in this build or are they coming from a jar file in binary form?
whilst waiting for feedback from Antti - I've put in a guard so the NPE can't happen - a message will be reported that we cant implement inlining and we'll fall back on closure - THIS WILL AFFECT PERFORMANCE OF THE GENERATED CODE - and so hopefully we can resolve what is leading to the NPE.
(In reply to comment #4) > Antti, can you possibly try something for me on your scenario that might help > me narrow things down? > > Can you remove the -XnoInline workaround I asked you to use and instead try > '-Xset:activateLightweightDelegates=false' - does it still fail? Yes, this seems to fix the problem: D:\work\napa\jnapa\core>ajc -nowarn -Xlint:ignore -Xset:activateLightweightDelegates=false -source 1.5 -target 1.5 -d bu ild\classes -cp ..\commons\utils\build\napa_utils.jar;lib\aspectjrt.jar;lib\dom4j-1.5.2.jar;lib\groovy-all-1.0-jsr-05.ja r;..\commons\test_commons\lib\junit.jar -sourceroots src;gen_src;test_src D:\work\napa\jnapa\core> I added the -nowarn and -Xlint:ignore, but also tried w/out them, so they do not seem to affect this bug. As for your other question, some aspects are in source form and some come from a jar, though not via inpath but via aspects in this project extending abstract aspects contained in one of the jars.
thanks for responding quickly! I think that description tells me what it is - i'll write a test program to verify.
yey! recreated
thanks to Antti I have recreated this and fixed it. The problem is due to the fast delegates we support that are based on the ASM bytecode toolkit. Fast delegates don't have any instructions loaded for methods within them - this causes a problem if the weaver attempts to inline around advice. Normally we know which types it is safe to create fast delegates for but this was a case we hadn't been testing, you need to have: - an abstract super aspect containing *inlinable around advice* - a concrete sub aspect The abstract super aspect needs to be on the classpath, not on the aspectpath or in source form. In this situation when the super aspect is resolved we see it on the classpath and think we can create a fast delegate - but we can't because we may want to extract the instructions from the around advice and inline them at some matched join point. The fix is a little ugly right now but this is quite serious and I wanted to get something minimal through so AJDT can ship its 1.3.1 version. The fix is to fallback to BCEL if we create a fast delegate and discover it is an aspect, ideally we could know if we were loading the supertype for an aspect and ensure it was loaded via BCEL but that's a little messier as when the resolution occurs we don't know the context in which it is occurring. couple of tests are failing now due to expecting ASM types for aspects sometimes, I'm working on fixing those then i'll commit.
fix available in latest dev build.
