I've put in some changes to fix the version of the problem I uncovered. If
you want to try it out there is a new dev build available on the download
page ( https://www.eclipse.org/aspectj/downloads.php ) or a new AspectJ
maven snapshot in repo.spring.io (version 1.8.9.BUILD-SNAPSHOT)
<repository>
<id>repo.spring.io</id>
<name>SpringSource snapshots</name>
<url>http://repo.spring.io/snapshot</url>
</repository>
If you get a chance to try them out, let me know if it makes any difference.
cheers,
Andy
On 26 January 2016 at 16:49, Andy Clement <andrew.clem...@gmail.com> wrote:
> 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> 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>
> 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> 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"><