Community
Participate
Working Groups
Build ID: M20080911-1700 Steps To Reproduce: Create an abstract aspect with a bounded generic type. Use that generic type as the return type of an abstract method. Create a concrete aspect which extends the abstract aspect with a type not valid within the bounds defined by the abstract aspect's generic type. This should cause a compiler error. Instead, a null pointer exception is thrown (see below). Code below was used to reproduce: public abstract aspect Abstract<T extends Integer> { public abstract T getT(); } // Number is not valid substitute for T public aspect Concrete extends Abstract<Number> { public Number getT() { return 5; } } This appears to occur only within Eclipse/AJDT as I cannot reproduce it in our Ant builds. AJDT Version: 1.6.2.20081105005554 AspectJ Version: 1.6.3.20081028135200 Incremental Compiler Optimizations: On Non-standard compiler options: -Xset:pipelineCompilation=false The NPE exceptions tracktrace is: java.lang.NullPointerException at org.aspectj.weaver.CrosscuttingMembers.setPerClause(CrosscuttingMembers.java:475) at org.aspectj.weaver.ResolvedType.collectCrosscuttingMembers(ResolvedType.java:560) at org.aspectj.weaver.CrosscuttingMembersSet.addOrReplaceAspect(CrosscuttingMembersSet.java:77) at org.aspectj.weaver.CrosscuttingMembersSet.addOrReplaceDescendantsOf(CrosscuttingMembersSet.java:113) at org.aspectj.weaver.CrosscuttingMembe ... oBuildJob.run(AutoBuildJob.java:238) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) Compile error: NullPointerException thrown: null
This looks like an AspectJ error even though it is only reproducible in AJDT land. Willing to look at it more if otherwise.
definetly aj
I thought it was in aj but as I couldn't reproduce outside of AJDT, I just took a shot. Thanks.
Created attachment 117210 [details] Code causing compiler error
After more investigation this morning, it doesn't look related to the return type at all. If its any help, an even simpler case is provided below. Looks like NPE occurs any time there would be a compilation error related to generic bounds/substitution: public interface Interface { } public class Class { } // class does not implement Interface public aspect Concrete extends Abstract<Class> { } public abstract aspect Abstract<T extends Interface> { } I've also noticed a similar bug related to generics and type substitution. This may be a duplicate, so I haven't yet reported a bug for it. In that scenario, I've setup some type inheritance which goes across projects (no aspect/inpaths, just Java dependencies). In doing so, it looks like there might be an issue with type erasure, as a valid generic type substitution doesn't compile. Oddly enough, I can only reproduce that compile failure when there are two projects. When placing all the code in a single project, the NPE reported for this bug gets thrown. This leads me to believe they're the same bug. I've attached code to reproduce the second scenario.
Can I ask why you are running with pipeline compilation switched off? Given that we don't test that mode at all it is effectively unsupported. However, I have recreated the scenario described in the first comment so will debug it now - but it only happens if I turn off pipeline compilation.
We've had this option set in our build since a bug was reported several months ago. We have attempted to remove this flag on a couple of occasions, but if memory serves we have run into other issues. When I get more time, I can tell you what issues, if any, we still see without the flag. I'll get back to you on that one.
Here is the command to get it to fail on command line: ajc -1.5 -proceedOnError -Xset:pipelineCompilation=false Abstract.java Concrete.java The problem is due to heading into the weaving process even though the aspect is broken (which is what -proceedOnError does, and that is default in AJDT) I've committed a change to cope with a broken aspect (and so the real error comes out). I've put in two testcases - one for your first scenario and one for the scenario in comment 5. If you can let me know why you still need pipeline compilation, that would be great - I don't like to see it used other than for debugging or a temporary workaround. There are a couple of known issues that are very hard to solve for pipelining. It might be one of those and so far they haven't made it into a release plan. If it is then you will probably need to continue using it - but it is worth checking if it is something I don't know about. cheers
