I see a couple of things of interest:
- the type is marked ConfigurableObject - there are numerous isAnnotationPresent checks guarding advice calls (checking if the type of ‘this’ in the method has the Configurable annotation).
Do you expect this type to be a ConfigurableObject? Are types further up this objects hierarchy marked with ConfigurableObject? I ask because weaving may differ if the types are processed in a different order on each OS (which can happen because an ordering is not enforced/required). If a type further up the hierarchy is woven first and matches the declare parents statement (from the spring aspect it is "declare parents: @Configurable * implements ConfigurableObject;”) then it would get the ConfigurableObject interface and then when we hit your ExistenceByIdSpecification we would not add the interface again (because we were inheriting it). But if hitting ExistenceByIdSpecification first we might add it here and then add it again when we hit the parent that also matches.
When this happens it is harmless, and not necessarily anything to worry about, it is just a different weave that basically does the same thing (although different weaves may offer a slight variance in performance). You could turn on the weaving output and see the order in which types are processed on different operating systems and see if there is a difference in ordering.
The isAnnotationPresent checks might be considered sub-optimal if the ‘alternate’ weaving ordering has determined they aren’t needed in this code - I’d need to recreate all this myself to debug further. When a pointcut element (like @this(Foo)) cannot be fully determined statically to be always true, it will insert a runtime check into the code that verifies it at runtime. It is possible these are also because on centos we aren’t weaving a super type of this type earlier than this type.
Thanks for testing the losing bounds fix, I’ll commit that now.
cheers, Andy
Hi Andy,
OK that fix looks like it worked. I'm doing some more testing but so far so good.
...but I'm wondering if there is another issue. I mentioned this briefly in the original email - the bytecode on the CentOS build looks quite different...it's larger with what looks like more references to the aspects. This might be a different issue so I'm happy to start a new thread / open a new issue.
I've include 3 files (attached). If you look at the Windows and Manjaro Linux ones they are identical. The CentOS one is the different one. There doesn't seem to be any problem with the code execution, but it doesn't look right, and I don't have the expertise to really determine if it's a problem or not. Can you have a look?
Anyway - big thanks for fixing this so quickly...:-)
<bytecode.zip>_______________________________________________ aspectj-users mailing list aspectj-users@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/aspectj-users
|