Community
Participate
Working Groups
Reported on the list on the 20090106 driver Looks related to rewrite of type locating in the AsmManager and AspectJElementHierarchy - possibly interacting with the new code to add import references to the model. java.lang.NullPointerException at org.aspectj.asm.AsmManager.sameType(AsmManager.java:857) at org.aspectj.asm.AsmManager.removeRelationshipsTargettingThisType(AsmManager.java:694) at org.aspectj.weaver.bcel.BcelWeaver.weave(BcelWeaver.java:1120) at org.aspectj.ajdt.internal.compiler.AjPipeliningCompilerAdapter.weaveQueuedEntries(AjPipeliningCompilerAdapter.java:435) at org.aspectj.ajdt.internal.compiler.AjPipeliningCompilerAdapter.queueForWeaving(AjPipeliningCompilerAdapter.java:371) at org.aspectj.ajdt.internal.compiler.AjPipeliningCompilerAdapter.afterProcessing(AjPipeliningCompilerAdapter.java:358) at org.aspectj.ajdt.internal.compiler.CompilerAdapter.ajc$after$org_aspectj_ajdt_internal_compiler_CompilerAdapter$5$6b855184(CompilerAdapter.aj:98) at org.aspectj.org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:652) at org.aspectj.org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:392) at org.aspectj.ajdt.internal.core.builder.AjBuildManager.performCompilation(AjBuildManager.java:975) at org.aspectj.ajdt.internal.core.builder.AjBuildManager.performBuild(AjBuildManager.java:301) at org.aspectj.ajdt.internal.core.builder.AjBuildManager.incrementalBuild(AjBuildManager.java:18
Diagnostics from Hermann. The problematic .class is one that will have been faulted into the model because it has advice that affects something we are incrementally building. java.lang.RuntimeException: Exception whilst walking up from target DepInjector.class file at org.aspectj.asm.AsmManager.sameType(AsmManager.java:863) at org.aspectj.asm.AsmManager.removeRelationshipsTargettingThisType(AsmManager.java:694) at org.aspectj.weaver.bcel.BcelWeaver.weave(BcelWeaver.java:1120) at org.aspectj.ajdt.internal.compiler.AjPipeliningCompilerAdapter.weaveQueuedEntries(AjPipeliningCompilerAdapter.java:435) at org.aspectj.ajdt.internal.compiler.AjPipeliningCompilerAdapter.queueForWeaving(AjPipeliningCompilerAdapter.java:371) at org.aspectj.ajdt.internal.compiler.AjPipeliningCompilerAdapter.afterProcessing(AjPipeliningCompilerAdapter.java:358) at org.aspectj.ajdt.internal.compiler.CompilerAdapter.ajc$after$org_aspectj_ajdt_internal_compiler_CompilerAdapter$5$6b855184(CompilerAdapter.aj:98) at org.aspectj.org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:652)
recreated! it is the usage of declare soft from a faulted in aspect
In my scenario the aspect containing declare soft is called X and the handle for the declare soft becomes: [=importProb/binaries<x(X.class] So I will fix two things: - cope with funky handles like that (in case an incorrect handle comes along) - try and fix the handle for declare soft. At the moment it does not look like declare softs are faulted in.
Also need to make sure this works in AJDT. If you are working with a small test project, can you attach it here, or send it my way?
OK - faulting in declare softs is more than I want to do right now. However I have put the right check into AsmManager now so that it does the right thing when it finds the end point is a file rather than a type. To go further with this, we need this code in AsmRelationshipProvider.getHandle(): IProgramElement ipe = asm.getHierarchy().findElementForSourceLine(sl); advice.handle = asm.getHandleProvider().createHandleIdentifier(ipe); to discover the declare soft rather than give up and decide the .class file is the closest it can get to that source file. There is a placeholding member in the .class file for the declare soft so I hopefully that will have the line number attached to it.
Andy Clement wrote: > I've committed the fix into AspectJ - attached is a patch you could > apply to your configuration if you wanted to try it. to confirm: applied this patch to my current aspectjweaver.jar and the problem is gone. Happily using incremental compilation within AJDT again.
