Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-users] bridge methods incorrectly marked as interface

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.webster@xxxxxxxxx> 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.clement@xxxxxxxxx> 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.webster@xxxxxxxxx> 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.clement@xxxxxxxxx> 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.webster@xxxxxxxxx> 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@xxxxxxxxxxx
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@xxxxxxxxxxx
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@xxxxxxxxxxx
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@xxxxxxxxxxx
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@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/aspectj-users


Back to the top