I’ve recreated it and am currently sorting it out. For me this code exhibits
the problem:
— Code.java —
class B<T extends SomeClass & SomeInterface> {}
class SomeClass {}
interface SomeInterface {}
aspect X {
declare parents: B implements java.io.Serializable;
}
—Code.java—
ajc -1.8 Code.java
javap B
class B<T extends SomeInterface> implements java.o.Serializable {
See how the type variable has lost the class bound. It only happens if you have
interface bounds in addition to a class bound. Maybe your problem isn’t caused
by doing declare parents but clearly there is a code path in AspectJ that
produces the wrong signature attribute - and maybe whatever you do causes us to
go down that path too.
I raised https://bugs.eclipse.org/bugs/show_bug.cgi?id=486612 to cover it.
cheers,
Andy
> On Jan 26, 2016, at 11:56 AM, Andy Clement <[email protected]> wrote:
>
> 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 <[email protected]
>> <mailto:[email protected]>> 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 <[email protected]
>> <mailto:[email protected]>> 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 <[email protected]
>> <mailto:[email protected]>> 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.<init>(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
>> [email protected] <mailto:[email protected]>
>> 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
>> [email protected] <mailto:[email protected]>
>> 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
>> [email protected] <mailto:[email protected]>
>> 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
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/aspectj-users
