Community
Participate
Working Groups
Using the attached example project, I added some comments to Aspect.aj and saved and got the following NPE: java.lang.NullPointerException at org.aspectj.ajdt.internal.compiler.lookup.AjLookupEnvironment.doDeclareAnnotati ons(AjLookupEnvironment.java:555) at org.aspectj.ajdt.internal.compiler.lookup.AjLookupEnvironment.weaveInterTypeDec larations(AjLookupEnvironment.java:410) at org.aspectj.ajdt.internal.compiler.lookup.AjLookupEnvironment.weaveInterTypeDec larations(AjLookupEnvironment.java:334) at org.aspectj.ajdt.internal.compiler.lookup.AjLookupEnvironment.doPendingWeaves (AjLookupEnvironment.java:227) at org.aspectj.ajdt.internal.compiler.lookup.AjLookupEnvironment.completeTypeBindi ngs(AjLookupEnvironment.java:132) at org.aspectj.org.eclipse.jdt.internal.compiler.Compiler.beginToCompile (Compiler.java:331) at org.aspectj.org.eclipse.jdt.internal.compiler.Compiler.compile (Compiler.java:348) at org.aspectj.ajdt.internal.core.builder.AjBuildManager.performCompilation (AjBuildManager.java:683) at org.aspectj.ajdt.internal.core.builder.AjBuildManager.doBuild (AjBuildManager.java:191) at org.aspectj.ajdt.internal.core.builder.AjBuildManager.incrementalBuild (AjBuildManager.java:109) at org.aspectj.ajde.internal.CompilerAdapter.compile (CompilerAdapter.java:117) at org.aspectj.ajde.internal.AspectJBuildManager$CompilerThread.run (AspectJBuildManager.java:165) I also got another NPE when I added some whitespace to MainClass.aj and saved it: java.lang.NullPointerException at org.aspectj.org.eclipse.jdt.internal.compiler.lookup.MethodBinding.getAnnotatio nTagBits(MethodBinding.java:410) at org.aspectj.ajdt.internal.compiler.lookup.AjLookupEnvironment.doDeclareAnnotati ons(AjLookupEnvironment.java:549) at org.aspectj.ajdt.internal.compiler.lookup.AjLookupEnvironment.weaveInterTypeDec larations(AjLookupEnvironment.java:410) at org.aspectj.ajdt.internal.compiler.lookup.AjLookupEnvironment.weaveInterTypeDec larations(AjLookupEnvironment.java:494) at org.aspectj.ajdt.internal.compiler.lookup.AjLookupEnvironment.weaveIntertypes (AjLookupEnvironment.java:220) at org.aspectj.ajdt.internal.compiler.lookup.AjLookupEnvironment.completeTypeBindi ngs(AjLookupEnvironment.java:162) at org.aspectj.org.eclipse.jdt.internal.compiler.Compiler.beginToCompile (Compiler.java:331) at org.aspectj.org.eclipse.jdt.internal.compiler.Compiler.compile (Compiler.java:348) at org.aspectj.ajdt.internal.core.builder.AjBuildManager.performCompilation (AjBuildManager.java:683) at org.aspectj.ajdt.internal.core.builder.AjBuildManager.doBuild (AjBuildManager.java:191) at org.aspectj.ajdt.internal.core.builder.AjBuildManager.incrementalBuild (AjBuildManager.java:109) at org.aspectj.ajde.internal.CompilerAdapter.compile (CompilerAdapter.java:117) at org.aspectj.ajde.internal.AspectJBuildManager$CompilerThread.run (AspectJBuildManager.java:165)
Created attachment 20041 [details] Test project
The failing line is: Annotation currentAnnotations[] = sourceType.scope.referenceContext.annotations; an awful lot of options for things that could be null. The file has changed recently and now the line number it would fail at is 587. I'm having trouble putting the test case into the multiIncremental harness - not sure why but when built from the harness i get a problem where the annotation on the ajc$declare member representing the first declare @type cannot be found. When built from command line the annotation is found no problem... not generics related so scheduling post M3
I *think* the fix for bug 85132 will also fix this one. In that bug the problem was that a change in the type hierarchy was never undone before the next incremental build. The only other change that could occur to a type that wasnt being undone correctly was an annotation change - so at the same time as undoing the type hierarchy change I undo the annotation change. I don't suppose there is any way you still have this project around Sian - so we can test the fix? (the attached project doesnt seem to fail for me...)
After a chat with Sian, the first problem reported here has gone. But there is a new problem to do with modifying an aspect containing a declare @type - on the incremental compile that occurs when you save the modification you fail to see a gutter annotation going out from the declare @type. I'm going to try adding a testcase for this to our incremental suite in AJ and see if I can recreate it there...
this is a horrible bug - i know exactly why it happens but its just a pain in the backside to fix. The problem is that declare @type is done up front (has to be) in the compile stage - this means the classfile produced by the compiler has the annotations against the type. Therefore when the weaver tries to apply declare @type again, the annotation is already there and so it does nothing. the fix is to make sure the class file coming out of the compiler does *not* have the annotation on it if it was declared upon it. that way the weaver can always do its job. its exactly the same problem we had for declare parents...
I've fixed this. I enabled TypeDeclarations in the compiler to remember what annotations they were originally declared with - this means declare @type statements may change the set when completing type bindings, but when the class is 'output' from the compile stage it is only tagged with the annotations it was declared with. This allows the weaver to do its job and correctly report weave info and relationships for declare @types. If we ever do declare @method/field/ctor during compilation then we'll need a similar fix for those. fix checked in, waiting on build.
build available.
