Community
Participate
Working Groups
Using the same AspectJ from an ANT task, has no problems. But form within Eclipse every compile results in the error below. I feel this is a major problem, escpecially since it is M4. java.lang.NullPointerException at org.aspectj.weaver.bcel.BcelWeaver.weave(BcelWeaver.java:1015) at org.aspectj.ajdt.internal.compiler.AjCompilerAdapter.weave (AjCompilerAdapter.java:300) at org.aspectj.ajdt.internal.compiler.AjCompilerAdapter.afterCompiling (AjCompilerAdapter.java:178) at org.aspectj.ajdt.internal.compiler.CompilerAdapter.ajc$afterReturning$org_aspect j_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:759) at org.aspectj.ajdt.internal.core.builder.AjBuildManager.doBuild (AjBuildManager.java:249) at org.aspectj.ajdt.internal.core.builder.AjBuildManager.incrementalBuild (AjBuildManager.java:158) at org.aspectj.ajde.internal.CompilerAdapter.compile(CompilerAdapter.java:117) at org.aspectj.ajde.internal.AspectJBuildManager$CompilerThread.run (AspectJBuildManager.java:191) NullPointerException thrown: null
Andy, it looks like getBcelObjectType is returning null... BcelObjectType classType = BcelWorld.getBcelObjectType(world.resolve(className)); if (classType.isAspect()) { <<<<<<< NPE here weaveAndNotify(classFile, classType,requestor); wovenClassNames.add(className); }
After some experimenting, reapplying the AspectJ nature in Eclipse seems to make it go away... Hm.
I made a change a little while ago to allow BcelWorld.getBcelObjectType() to return null (and the caller had to deal with it being null - as the javadoc says). I believe it can only be null if the delegate for a particular type is an eclipse thing rather than a Bcel thing. If I didn't allow getBcelObjectType() to return null then it was just blowing up with a classcastexception. Unfortunately this caller wants a bcel thing back and doesn't allow for null. However, given that the question it is asking is so simple 'isAspect()' - I don't think it needs the delegate immediately, so I've modified it to ask the resolved type whether its an aspect before trying to retrieve the delegate. I'm actually worried that the type it is processing is one of these 'MissingResolvedTypeWithKnownSignature' objects that are now causing us grief through the codebase... Anyway, I've made the change and committed it - I don't know if it'll fix the problem, but if/when it goes wrong there should be better diagnostics. Does it only happen on incremental builds or on full builds too? Removing/readding the nature would cause a full build which you seem to imply doesnt exhibit this problem. If it happens again, press the build button on the toolbar to do a full AJ compile and see what happens.
Improved handling code is in the latest dev build - will make it into AJDT next week.
I'm still using M4. The error returned now that I restarted Eclipse (after a full system shutdown) to continue my work. I had to click away a window 4x (or had to click 4x on the OK button, or it simply didn't catch the first 3 clicks, can't tell the difference). When I click the "Build a AspectJ" button in the toolbar, compilation starts and then the error window pops up once. Reapplying the nature made it go away again. Full build works also. I stopped and started Eclipse and the problem is NOT present. Well well, I seem to have found a ellusive one. I will see what happens when I do a full reboot. To be continued?
I believe the AJDT team are upgrading to the latest AJ imminently - hopefully we'll get more diagnostics if it goes wrong in that version...
please can you retry with the latest AJDT to create more diagnostics?
Just updated and things do look better; no errors so far. I have some hindsight that might prove useful. The orginal aspect was declared inside a .java file, not a .aj file. Eclipse had problems with it from the start, but everything worked, because I use ANT to compile and deploy. And once everything was compiled, Eclipse correctly started the unittest. After I got tired of have to go through ANT all the time, I decide to dive into the aspect syntax error (everything is a matter of priority; it worked) and found my naming mistake. As of then the problem did not reoccur. So I assume it was related to the extention.
thanks for the update. Eclipse has problems because the eager parser for java is used if its in a .java file. The compiler should always do the right thing when a build actually occurs, but you have to look 'past' the red squigglies whilst editing the file :)
I'm resolving this as fixed then - please reopen if you see any problems again :)
** If you're looking for the "Top 10 downloads contains stale data" bug mentioned in the Webmaster update, it's actually Bug 122529 **
sigh... * sound of head bashing keyboard *
Here, let me help you with that... * pulls heavy sledgehammer from under cloak *
