Community
Participate
Working Groups
Reported on the list by Tom Dunstan. @Aspect public class MixinAspect { @DeclareMixin(value = "test.Foo") public static Runnable foo(Object target) { return new DebugDefault(); } public static class DebugDefault implements Runnable { public void run() { System.out.println("Hi there from MixinAspect"); } } } package test; public class Foo { public static void main(String[] args) { System.out.println(Arrays.toString(new Foo().getClass().getInterfaces())); ((Runnable) new Foo()).run(); } } MixinAspect is in one project, the Foo type is in another with an aspectpath dependency on the MixinAspect project. NPE: java.lang.NullPointerException at org.aspectj.asm.internal.ProgramElement.addChild(ProgramElement.java:398) at org.aspectj.weaver.model.AsmRelationshipProvider.addChildNodes(AsmRelationshipProvider.java:611) at org.aspectj.weaver.model.AsmRelationshipProvider.createHierarchy(AsmRelationshipProvider.java:425) at org.aspectj.weaver.model.AsmRelationshipProvider.addRelationship(AsmRelationshipProvider.java:121) at org.aspectj.weaver.bcel.B ... OKEINTERFACE java.lang.Runnable.run ()V reason is that the code in AsmRelationshipProvider.createIntertypeDeclaredChild() is encountering a MethodDelegateTypeMunger.
step 1 here is avoiding the exception - so just realising that the mechanism used to implement mixin is not supported for binary aspect faulting. This means the UI feedback on the affect of declaremixin is limited, but it does work just fine.
changes to avoid failing are in
relationships were looking 'wierd' for declare mixin. For the basic example here there are 3 type mungers created: - a new parents munger for Runnable - a new method delegate munger for run - a new field host for the instance of DebugDefault We were 'having a go' at setting the source locations for the first two, but not the third. Ironically this led to the situation where the relationships for the first two were junk whilst the one without a source location caused creation of a more suitable relationship. Due to the use of javac to build purely annotation based aspects, we don't know a lot about source locations for annotations. We don't know where the @DeclareMixin is declared, we don't know where DebugDefault is declared. We could guess where 'run()' is declared if the debug info for the instructions within it are included in the compiled aspect. A more straightforward approach is just to say "this aspects declares stuff on that type" - giving navigation from the MixinAspect to the type test.Foo. This works - it isn't brilliant as for a complex aspect you may not know which parts of the aspect are in effect, but it is better than what we have now. To get detailed output, turn on 'AspectJ Compiler>Information>Output weaving info messages to problems view' and you'll get more accurate info in the problems view.
fixed all I plan to do here for 1.6.5. Enhancements in bug 280675 cover making this even better.
