Bug 399590 - Bad generics signature generated
Summary: Bad generics signature generated
Status: RESOLVED FIXED
Alias: None
Product: AspectJ
Classification: Tools
Component: Compiler (show other bugs)
Version: 1.6.9   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: 1.7.2   Edit
Assignee: aspectj inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-01-31 04:17 EST by Manish Java CLA
Modified: 2013-02-05 11:28 EST (History)
2 users (show)

See Also:


Attachments
Sample Maven project to reproduce the problem (15.64 KB, application/x-zip-compressed)
2013-02-04 01:07 EST, Manish Java CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Manish Java CLA 2013-01-31 04:17:35 EST
Please see http://jira.springsource.org/browse/SPR-5949.  The bug ID https://bugs.eclipse.org/bugs/show_bug.cgi?id=284297 was raised for this issue and fixed in version 1.6.6.  We were using AspectJ version 1.7.1 and got hit by this bug today.

During investigation we have found that the problem does not occur with AspectJ versions 1.6.6 - 1.6.8 but it resurfaces with version 1.6.9 and can be reproduced all the way up to the current version 1.7.1.
Comment 1 Andrew Clement CLA 2013-01-31 12:08:22 EST
Are you sure it is the same signature problem exactly? I took the code from spr5949 and cannot make it fail in the same way.  I don't see the P signatures in the resultant compiled code and I can use the woven classes just fine.

Can you let me know your sequence of steps? What version of Spring - is it 2.5.5/2.5.6/3.0M3 as mentioned in the spring jira? What version of Java compliance? (1.5/1.6/1.7?)

Per the spring jira i compiled these 3 files:

public class DomainObject<E> { }

public class DomainLogic<E, D extends DomainObject<E>> { }

@org.springframework.beans.factory.annotation.Configurable
public class FancyDomainLogic<E, D extends DomainObject<E>> extends DomainLogic<E, D> { }

using Spring 2.5.6 jars, classpath contained spring-tx.jar/spring-beans.jar

I created a zip of the resultant class file, then a binary weave applying the aspects:

ajc -aspectpath spring-framework-2.5.6/dist/weaving/spring-aspects.jar -inpath code.zip -outjar code2.zip

then compiled this against the result:

public class FancyDomainLogicImpl <E, D extends DomainObject<E>> extends FancyDomainLogic<E, D> { }

all worked fine. I'm happy to fix it but I will need to recreate a failing scenario.  I also tried a separate aspect that I knew would really target the type signature and change it, still no problems.

If you do have a failing signature message, can you attach it here?

thanks
Comment 2 Manish Java CLA 2013-01-31 23:17:32 EST
Hi Andrew

Let me create a sample using the bare minimum classes that will reproduce the problem.
Comment 3 Manish Java CLA 2013-02-04 01:07:51 EST
Created attachment 226487 [details]
Sample Maven project to reproduce the problem

Please find a sample Maven project that can be used to reproduce the error.
Comment 4 Andrew Clement CLA 2013-02-04 16:36:45 EST
thanks so much for taking the time to create a testcase.  I've fixed it all up and the latest 1.7.2.BUILD-SNAPSHOTs in maven include the fix.  The failing case needed a slightly complex generics signature which your type 'Cage' had, so similar to the problem previously fixed but a different manifestation.
Comment 5 Manish Java CLA 2013-02-05 02:47:17 EST
Hi Andrew

Thanks a ton for addressing this so quickly.  Is there any guidance on when 1.7.2 will be released publicly?
Comment 6 Manish Java CLA 2013-02-05 03:05:20 EST
Also, where is the source code and how can one get access to it?  I checked out the repository link to Eclipse Git but could not understand where release 1.7.2 code is maintained.
Comment 7 Andrew Clement CLA 2013-02-05 11:28:41 EST
1.7.2 is quite imminent, couple of weeks I think. Just a few loose ends to wrap up.

If you have the git repo cloned shown on here:

http://git.eclipse.org/c/aspectj/org.aspectj.git

Then 'master' is the current active development code. All the previous releases are dealt with as tags, there are no branches for releases. Run 'git tag' and you will see V1_1_0 > V1_7_1. When 1.7.2 is out, it'll get tagged there too. The fix I made for this was in BoundedReferenceType to ensure it overrode getSignatureForAttribute() (IIRC).