Bug 245734 - AJDT throws a RuntimeException from EclipseResolvedMember.getAnnotations
Summary: AJDT throws a RuntimeException from EclipseResolvedMember.getAnnotations
Status: RESOLVED FIXED
Alias: None
Product: AspectJ
Classification: Tools
Component: Compiler (show other bugs)
Version: 1.6.1   Edit
Hardware: PC Windows XP
: P3 major (vote)
Target Milestone: 1.6.2   Edit
Assignee: AJDT-inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-08-29 14:27 EDT by Jason Naylor CLA
Modified: 2008-09-24 12:01 EDT (History)
1 user (show)

See Also:


Attachments
Small testcase that can reproduce the bug. (2.05 KB, application/octet-stream)
2008-09-22 16:07 EDT, Jason Naylor CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jason Naylor CLA 2008-08-29 14:27:06 EDT
Build ID: N/A

Steps To Reproduce:
This exception is happening for us in both Eclipse 3.4 and 3.3 when we run an incremental build on one of our projects.

We are using an aspect to declare an annotation on a class in the project, and we only started seeing this exception after we added it.  

A clean build on the project never throws the exception, only an incremental build.


More information:
The Exception Stack Trace:

java.lang.RuntimeException
at org.aspectj.ajdt.internal.compiler.lookup.EclipseResolvedMember.getAnnotations(EclipseResolvedMember.java:78)
at org.aspectj.ajdt.internal.compiler.lookup.AjLookupEnvironment.doDeclareAnnotations(AjLookupEnvironment.java:794)
at org.aspectj.ajdt.internal.compiler.lookup.AjLookupEnvironment.weaveInterTypeDeclarations(AjLookupEnvironment.java:592)
at org.aspectj.ajdt.internal.compiler.lookup.AjLookupEnvironmen ... 
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)

Compile error: RuntimeException thrown: not yet implemented - please raise an AJ bug


I was going to include the AJDT Event log for the build but it is very long, and mostly unremarkable, 
so I have included only the section for the project where the exception was thrown.

11:9:50 Build kind = INCREMENTALBUILD
11:9:50 Project=ICODES, kind of build requested=Incremental AspectJ compilation
11:9:50 build: Examined delta - source file changes in required project ICODES
11:9:51 Found state instance managing output location : C:\jnaylor\Java_Dev\workspace\ICDM
11:9:51 Failed to find a state instance managing output location : C:\jnaylor\Java_dev\workspace\Dependencies\MARVEL\resources
11:9:51 Failed to find a state instance managing output location : C:\jnaylor\Java_Dev\workspace\GSG
11:9:52 Failed to find a state instance managing output location : C:\jnaylor\Java_dev\.build\Launch4J
11:9:52 Preparing for build: planning to be an incremental build
11:9:52 Starting incremental compilation loop 1 of possibly 5
11:9:52 AJDE Callback: finish. Was full build: false
11:9:52 Timer event: 2172ms: Total time spent in AJDE
11:9:54 Timer event: 47ms: Create element map (0 rels in project: ICODES)
11:9:54 Types affected during build = 0
11:9:54 Timer event: 0ms: Add markers (0 markers)
11:9:54 Timer event: 3735ms: Total time spent in AJBuilder.build()
11:9:54 ===========================================================================================


This is occurring frequently, but not every time so we haven't been able to narrow down a reasonable sized test case.
Comment 1 Andrew Clement CLA 2008-08-29 14:32:07 EDT
An AspectJ problem
Comment 2 Andrew Clement CLA 2008-08-29 16:12:27 EDT
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.
Comment 3 Jason Naylor CLA 2008-08-29 16:33:12 EDT
(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. 

Comment 4 Jason Naylor CLA 2008-09-19 18:09:14 EDT
This is causing us considerable delays now.  I'm going to try and produce a small scale test for this.
Comment 5 Andrew Clement CLA 2008-09-19 19:30:09 EDT
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.
Comment 6 Jason Naylor CLA 2008-09-22 16:07:55 EDT
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.
Comment 7 Jason Naylor CLA 2008-09-22 16:32:54 EDT
(In reply to comment #6)
Note: I have only tested these steps in Eclipse 3.3.2, not 3.4

Comment 8 Andrew Clement CLA 2008-09-22 19:59:53 EDT
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.
Comment 9 Jason Naylor CLA 2008-09-23 20:58:39 EDT
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)
Comment 10 Andrew Clement CLA 2008-09-24 12:01:44 EDT
I wonder what my fix does then ;)

closing for now.