Community
Participate
Working Groups
If @DeclareParents is used to add an interface, the interface must either * not have a super-interface * if it does have a super-interface, then all the the methods of the super-interface must be re-declared in the sub-interface. If an attempt is made to add an interface that has a parent, the target class will refer to a member field based on the name of the class that declared the method. This causes methods that are not declared on the top level interface to fail due to a NoSuchFieldError. Test case attached will result in the following error... Exception in thread "main" java.lang.NoSuchFieldError: ajc$test_DeclareParentsAspect$test_A at test.TargetBad.doA(TargetBad.java:1) at test.Main.main(Main.java:21) Also see TargetBad.jad
Created attachment 53575 [details] test case that demonstrates the bug To run test, the build.xml property ${aspectj.libs} must be set.
The problem here is that the the MethodDelegateTypeMunger uses the type of the method to generate the code that accesses the field. If the method is from a supertype then it gets it wrong. It should have been told the type of the field on construction then it wouldn't have this problem. Changing the MethodDelegateTypeMunger ctor to take the fieldType (and passing it from AtAjAttributes.handleDeclareParentsAnnotation()) is not difficult but it causes us to change the serialized form of the attribute for the type munger (as there is a new field). I don't want to change the serialized form for 1.6.3. I tried modifying the method passed to the type munger to use the field type rather than the declaring type of the method - and although this works in this case, we use the real method to do other things like lookup annotations that need to be coped across, so we cannot damage the method in this way. testcase is in 1.6.3 tests - commented out. deferring this bug.
*** Bug 258788 has been marked as a duplicate of this bug. ***
do this asap in 1.6.4
ok... I really wanted to put this fix in. The problem is that changing the serialized form of the attribute to include more information requires me to rev the version number for the entire weaver (so that new weavers know to expect it and old weavers dont try looking for it - instead putting out a message saying they cant understand the code built with the later compiler/weaver). However, that always causes a headache as people don't understand that once they move their tools up to the latest version, they have to move to that version on the build systems and in their runtime environment. Given that this bug only affects annotation style declare parents and only breaks for a subset of users exercising that functionality, I don't want everyone to suffer. So, i've come up with a scheme that will only affect users who are using annotation style decp. I've added a new attribute kind, called MethodDelegate2 - this is similar to MethodDelegate but includes the necessary information to address this bug. AspectJ1.6.4 will only produce MethodDelegate2 style attributes. Any older MethodDelegate attributes it encounters are upgraded to MethodDelegate2 when read in from the .class file. This means the version number of the class file will not be rev'd on this occasion. And that means failures will only be seen by users building annotation style decp code with 1.6.4 then attempting to use it with a 1.6.3 weaver - they need to upgrade that weaver. Users not exercising anno style decp will not notice and can successfully deploy 1.6.4 code on 1.6.3 weavers. test and fix committed.
