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 <andrew.clem...@gmail.com> 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 <tim.webs...@gmail.com
>> <mailto: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.<init>(L/Identifiable;)V"
>> type="java.lang.NoSuchMethodError"><