Typically this would end up being that the JVM on the target OS just happens to 
put things in a different place on the heap which might then cause things to be 
iterated over in a different order. For example if we slot a bunch of objects 
into a ‘Set’ without caring about an order an then ask for all the entries. It 
will typically be a bug in the code that is accidentally relying on an ordering 
when it shouldn’t - and we’ve been getting away with it because we’ve never 
seen this other order before or in any testing. I presume you are not doing 
anything that might affect the type definition, like an inter type declaration 
or declare parents? (Although you might be advising code within the affected 
type).

I would first try it on my linux (ubuntu i think I have)  but if that doesn’t 
show an issue I’d probably try running a centos virtual machine or some such. 
If all else fails I’d need to construct you some debug builds to perhaps 
collect extra diagnostics.  Hmm, do you compile that original source on centos 
or just weave it there?  I’m vaguely wondering if the java compiler used to 
build the original source produces a subtley different class file on centos vs 
windows.

cheers,
Andy

> On Jan 26, 2016, at 9:09 AM, Tim Webster <tim.webs...@gmail.com> wrote:
> 
> Hi Andy,
> 
> I'm trying to come up with a sample project but so far no luck - it's 
> behaving itself so far.  I'll keep trying though.
> 
> Like I said it only seems to happen in CentOS at the moment.  I'd be 
> surprised if it had anything to do with the OS itself, but my point is that 
> even if I did come up with a sample do you think you could reproduce the 
> conditions?  Is there anything else I can give you in the meantime (bytecode, 
> source code, etc)>
> 
> Thanks,
> 
> Tim
> 
> 
> On Tue, Jan 26, 2016 at 4:29 PM, Andy Clement <andrew.clem...@gmail.com 
> <mailto:andrew.clem...@gmail.com>> wrote:
> Hi Tim,
> 
> I'm certainly interested in more details. I haven't heard of that problem but 
> I suspect although we have some regression tests for generics we don't have a 
> lot exercising multiple bounds. I'll have a look in the code but as you say, 
> a sample that exhibits the problem will enable me to fix it much quicker (or 
> sort out a temporary workaround - maybe something silly like reordering the 
> bounds in the source code).  Please raise a bug and share any more info there 
> or with me on email.
> 
> cheers,
> Andy
> 
> On 26 January 2016 at 03:26, Tim Webster <tim.webs...@gmail.com 
> <mailto:tim.webs...@gmail.com>> wrote:
> Hi,
> 
> I'm seeing a problem where a class with multiple bounds is 'losing' one of 
> its bounds after weaving occurs.
> 
> Even more strange is that it is only happening on a specific platform.
> 
> a brief outline of the problem:
> 
> Source class:
> 
> public class ExistenceByIdSpecification<D extends AbstractDomainObject & 
> Identifiable> extends ExistenceSpecification<D> implements 
> IExistenceByIdSpecification
> 
> What happens is the 'AbstractDomainObject' bound (which is a class) is 
> disappearing, and in the bytecode we end up with something like this:
> 
> public class ExistenceByIdSpecification<D extends Identifiable> extends 
> ExistenceSpecification<D> implements IExistenceByIdSpecification, 
> org.springframework.beans.factory.aspectj.ConfigurableObject
> 
> 
> this results is a runtime error whenever the constructor is called (I've 
> removed package names - this is from a unit test):
> 
> 
> ExistenceByIdSpecification.&lt;init&gt;(L/Identifiable;)V" 
> type="java.lang.NoSuchMethodError"><![CDATA[java.lang.NoSuchMethodError: 
> ExistenceByIdSpecification.<init>(L/Identifiable;)V
>         at 
> ExistenceByIdSpecificationTest.<init>(ExistenceByIdSpecificationTest.java:33)
> 
> 
> 
> Also, the bytecode for the class is quite a bit larger on the environment 
> where this isn't working properly - it looks like stuff related to 
> @Configurable is repeated.
> 
> I'm suspecting AspectJ here because when I compile the code with AspectJ 
> disabled, the bytecode looks correct.
> 
> The environments details I've tried are:
> 
> works properly:
> Windows 7
> Manjaro Linux (current version)
> Oracle JDK 1.7.0_79
> AspectJ 1.8.6
> 
> Doesn't work:
> CentOS 7
> Oracle JDK 1.7.0_79, Oracle JDK 1.8.0_65, OpenJDK 1.7.0
> AspectJ 1.8.6, 1.8.8
> 
> Unfortunately we want to target CentOS as a build platform, so that's why 
> this is a problem for us!
> 
> I've only included basic details here to see if anyone has heard of this 
> problem.  I'm happy to provide more detail if required.  I know that a sample 
> project is ideal, but I may struggle to reproduce that (although I will try).
> 
> 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
> 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

Reply via email to