Wanted to draw a line under this thread mentioning what Tim and I discovered. Tim kindly put some time in to creating a testcase that reproduced the issue and it showed me a couple of issues with bridge method creation when it is done by the weaver (as opposed to the compiler, which also does some bridge method creation). These will both be fixed in the upcoming 1.8.6.
cheers Andy > On May 11, 2015, at 1:11 PM, Tim Webster <tim.webs...@gmail.com> wrote: > > Hi Andy, > > I'll answer what I can now: > > I've tried with 1.8.3 and 1.8.5, same result. > > I'll send you the aspect we're using privately if that's OK. > > What is 'binary weaving'? I've only heard of load-time and compile time > weaving... > > Will try some of your suggestions tomorrow when I'm in the office... > > Cheers! > > Tim > > > > > > > On Mon, May 11, 2015 at 7:55 PM, Andy Clement <andrew.clem...@gmail.com > <mailto:andrew.clem...@gmail.com>> wrote: > Hey, > > So we do indeed see the rogue entry in that javap: > > public int compareTo(java.lang.Object); > flags: ACC_PUBLIC, ACC_BRIDGE, 0x200 > > Who on earth put that 0x200 in there! (ACC_INTERFACE) > > Question going through my mind: > - what aspects are applying to the class containing this method? (What kind > of pointcuts/advice) > - if you still use the aspectj compiler but no aspects apply to this class, > does it still break that method? > - what version of AspectJ is in use? Have you tried with 1.8.5? > - Would it work if binary weaving rather than compile time weaving? > > But even if I knew all the answers to those questions, I’m not sure it’ll > help me pin it down - I’d be trying to recreate it just like you are. One > difference between compiling in different contexts (in the IDE or with maven) > is the ordering of compilation, which can sometimes influence things. The > ordering can be influenced by the names of things so in trying to recreate it > can be important to keep the type names/package names the same - not just > that you have a compareTo method that needs a bridge method. It is possible > to turn on verbose mode to see the compile order and confirm how it varies > between the two. > > I could probably fix it very quickly if I could have it failing locally for > me. We could create some debug builds but it’d take a while to home in on the > issue. If I’m debugging it myself I’m probably putting breakpoints in a few > places: org.aspectj.apache.bcel.classfile.Method constructor that takes a > modifiers set. the setModifiers in that same area of the code. There are a > number of representations of Methods (JDT, AspectJ, BCEL) - any of them could > be making a mistake. > > cheers, > Andy > >> On May 11, 2015, at 1:39 AM, Tim Webster <tim.webs...@gmail.com >> <mailto:tim.webs...@gmail.com>> wrote: >> >> Hi Andy, >> >> I'm struggling to reproduce this in a separate project, although it still >> occurs in the original project. >> >> Not sure what to try next...any ideas? >> >> Tim >> >> >> On Fri, May 8, 2015 at 4:07 PM, Andy Clement <andrew.clem...@gmail.com >> <mailto:andrew.clem...@gmail.com>> wrote: >> Modifiers are played with in a number of places, if you can create a bit of >> sample code that shows the problem I’m happy to look into it. I tried to >> create the problem but couldn’t. >> >> What does the javap -verbose output look like for the woven result (rather >> than the decompiler you are using). >> >> cheers, >> Andy >> >>> On May 8, 2015, at 6:27 AM, Tim Webster <tim.webs...@gmail.com >>> <mailto:tim.webs...@gmail.com>> wrote: >>> >>> >>> Hi, >>> >>> In our woven aspectJ code, it seems that bridge methods are being >>> incorrectly marked as interfaces. >>> >>> for example, in the following (decompiled) class here is the non-woven >>> compareTo() method: >>> >>> public int compareTo(TopicId topicId) >>> { >>> DocumentTypeId documentTypeId = (DocumentTypeId)topicId; >>> int result = super.compareTo(topicId); >>> if(0 == result) >>> result = doCompareTo(documentTypeId); >>> return result; >>> } >>> >>> public volatile int compareTo(Object x0) >>> { >>> return compareTo((TopicId)x0); >>> } >>> >>> >>> >>> And here is the woven version: >>> >>> >>> public int compareTo(TopicId topicId) >>> { >>> DocumentTypeId documentTypeId = (DocumentTypeId)topicId; >>> int result = super.compareTo(topicId); >>> if(result == 0) >>> result = doCompareTo(documentTypeId); >>> return result; >>> } >>> >>> public volatile interface int compareTo(Object obj) >>> { >>> return compareTo((TopicId)obj); >>> } >>> >>> >>> This is causing some static analysis tools to fail, so it's a problem. >>> >>> Does anyone have any idea where I can start with investigating why this >>> would be happening? >>> >>> Thanks, >>> >>> >>> >>> >>> >>> _______________________________________________ >>> aspectj-users mailing list >>> aspectj-users@eclipse.org <mailto:aspectj-users@eclipse.org> >>> To change your delivery options, retrieve your password, or unsubscribe >>> from this list, visit >>> https://dev.eclipse.org/mailman/listinfo/aspectj-users >>> <https://dev.eclipse.org/mailman/listinfo/aspectj-users> >> >> _______________________________________________ >> aspectj-users mailing list >> aspectj-users@eclipse.org <mailto:aspectj-users@eclipse.org> >> To change your delivery options, retrieve your password, or unsubscribe from >> this list, visit >> https://dev.eclipse.org/mailman/listinfo/aspectj-users >> <https://dev.eclipse.org/mailman/listinfo/aspectj-users> >> >> _______________________________________________ >> aspectj-users mailing list >> aspectj-users@eclipse.org <mailto:aspectj-users@eclipse.org> >> To change your delivery options, retrieve your password, or unsubscribe from >> this list, visit >> https://dev.eclipse.org/mailman/listinfo/aspectj-users >> <https://dev.eclipse.org/mailman/listinfo/aspectj-users> > > _______________________________________________ > aspectj-users mailing list > aspectj-users@eclipse.org <mailto:aspectj-users@eclipse.org> > To change your delivery options, retrieve your password, or unsubscribe from > this list, visit > https://dev.eclipse.org/mailman/listinfo/aspectj-users > <https://dev.eclipse.org/mailman/listinfo/aspectj-users> > > _______________________________________________ > aspectj-users mailing list > aspectj-users@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe from > this list, visit > https://dev.eclipse.org/mailman/listinfo/aspectj-users
_______________________________________________ aspectj-users mailing list aspectj-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/aspectj-users
