Summary: | AJDT throws a RuntimeException from EclipseResolvedMember.getAnnotations | ||||||
---|---|---|---|---|---|---|---|
Product: | [Tools] AspectJ | Reporter: | Jason Naylor <jason.naylor+eclipse> | ||||
Component: | Compiler | Assignee: | AJDT-inbox <AJDT-inbox> | ||||
Status: | RESOLVED FIXED | QA Contact: | |||||
Severity: | major | ||||||
Priority: | P3 | CC: | aclement | ||||
Version: | 1.6.1 | ||||||
Target Milestone: | 1.6.2 | ||||||
Hardware: | PC | ||||||
OS: | Windows XP | ||||||
Whiteboard: | |||||||
Attachments: |
|
Description
Jason Naylor
2008-08-29 14:27:06 EDT
An AspectJ problem Can you give me a definition of your annotation (fields and their types and any default values) - and the declare @type statement? you may be able to work around it by turning off pipeline compilation. (In reply to comment #2) > Can you give me a definition of your annotation (fields and their types and any > default values) - and the declare @type statement? > Annotation Def: @Retention(RetentionPolicy.RUNTIME) @Target(ElementType.TYPE) public @interface Subscribable { } Declare statement: declare @type: Cargo : @Subscribable; > you may be able to work around it by turning off pipeline compilation. No dice. This is causing us considerable delays now. I'm going to try and produce a small scale test for this. let me know how you get on, I cannot recreate it. I have an annotation, a class and an aspect doing declare @type of the anno onto the class. I've tried incremental builds where I just change each of the 3, and it always works. I've no doubt there is an issue, but can't see what is triggering it. Created attachment 113182 [details]
Small testcase that can reproduce the bug.
The project zipped up in this file can reproduce the bug:
Steps to reproduce:
Get the project into eclipse.
1. Turn off automatic build.
2. Clean the project ( or make sure it is clean )
3. change the import in class generated.C to fakepackage.B
4. build the project.
5. change the import back to realpackage.B
6. build the project.
(In reply to comment #6) Note: I have only tested these steps in Eclipse 3.3.2, not 3.4 I just tried with that sample as a testcase (it didnt fail...) so I imported it into my eclipse (3.4) and it didnt fail, so I fired up my eclipse 3.3 build that has the latest dev build of AJDT installed (1.5.4.200809111249 it seems) and it didnt fail in there either. On changing it to 'fakepackage' and forcing the build, I get 9 errors, but when I change it back to realpackage, they disappear and it builds OK. I've decided to change the AspectJ code to plug in the necessary annotation transform code rather than just throwing the exception for which this bug was originally raised. The annotation transform code does not handle all cases (the intent is to cover them as they crop up since there are so many to deal with) - but it already handles many straightforward cases. This change passes all my tests so I have committed it. I wish I could recreate this scenario to know it would help you though. But... I am currently only committing changes into Eclipse 3.4 AJDT - commits into Eclipse 3.3 aren't happening frequently right now and the interface between ajdt/aspectj has changed in the 3.4 stream so some AJDT changes will need backporting to AJDT on Eclipse 3.3 in order to allow me to drop in a new AspectJ. I'd planned on doing that once 1.6.2 went out (a weeks time). However, if you could confirm it fails for you in the Eclipse 3.4 right now, then that might be a way to confirm my proposed fix addresses it, and then I'll know it is definetly worthwhile putting a new AspectJ into Eclipse 3.3 AJDT sooner rather than later. Sorry for all the trouble here. I hadn't updated to the latest dev build for eclipse 3.3. The latest one no longer reproduces this problem. Eclipse 3.4 threw a different exception for us (a NPE with almost the same stack trace) with the release version, but the dev build no longer reproduced. And here I was so happy I finally got a small test case for it. I guess this bug can be closed at least until I see it crop up again. ;) (In reply to comment #8) I wonder what my fix does then ;) closing for now. |