Community
Participate
Working Groups
Build ID: I20071101-2000 Steps To Reproduce: 1.Create java Class as follows public class Test { private void test() { } } 2. Add APT processor to the Java project (I used APTDemo processor from here --> http://www.eclipse.org/jdt/apt/index.html) 3. Change "private" to "public" in method declaration above On this change ElementChangedEvent is fired. When I get delta by calling IJavaElementDelta delta = event.getDelta(); I expect the array of affected children in this delta to be non-empty, however IT IS empty. If I remove annotation processor from the Java project, behavior is back to expected. This happens to ALL the deltas for all the changes that I tried. This is a BIG problem, since as far as I can see, when the APT processor is enabled on Java project, the delta is pretty much looses it's meaning. More information:
Can you attach the code that you're using to register the element listener and read the delta?
Hi Walter I am using EXTREMELY simple code to detect it public class Test implements IObjectActionDelegate, IElementChangedListener { public void setActivePart(IAction action, IWorkbenchPart targetPart) { // TODO Auto-generated method stub } public void run(IAction action) { JavaCore.addElementChangedListener(this); } public void selectionChanged(IAction action, ISelection selection) { } public void elementChanged(ElementChangedEvent event) { IJavaElementDelta delta = event.getDelta(); IJavaElementDelta[] affectedChildren = delta.getAffectedChildren(); } } Just invoke it in my selfhost environment
I'll check it out.
I am able to reproduce this in HEAD and in the 3.3.x maintenance branch. It does not occur in Eclipse 3.2.2. Still trying to narrow in exactly when it got broken. The problem seems to only affect deltas sent during reconcile; the delta sent on a save/build is not affected. It occurs even though the file being edited contains no annotations. It occurs even when running under a 1.5 JRE, in which case none of the JSR269 plugins are loaded.
This is probably already known, but just to get it on record, I am running into this problem also with IJavaElementDelta.getAnnotationDeltas() returning empty.
If one of the commenters has the time and capability to help with narrowing down exactly which release this got broken in, that will help with troubleshooting. It works in 3.2.2, but not in the current tip of the 3.3.x maintenance branch; I haven't yet determined whether it works in 3.3.0 or 3.3.1.
I can also reproduce the bug in the 3.3.1 release. If processing is enabled and there are processors on the factory path, but all the processors are disabled, the bug does not occur. If a processor is enabled, the bug occurs, even though there are no annotations being processed. Adding Olivier and Jerome for early warning, since the fix to this may involve JDT Core changes.
Behavior in Eclipse 3.3.0 is the same as 3.3.1 and later.
The problem seems to be the call to resetAST(), in org.eclipse.jdt.apt.core.internal.env.ReconcileEnv.close(). Commenting out that line, while it will cause problems with type generation during reconcile, solves this problem. As a temporary workaround it is possible to turn off reconcile-time APT processing. This option is settable in the "Annotation Processing" preferences; it's called "enable processing in editor". I'll have to investigate further to figure out what the right "real" fix is.
What ReconcileContext.resetAST() does is set this.operation.ast = null. I am guessing this also causes the Java element delta to be discarded, and then recomputed; but when it is recomputed, the difference is not a difference any more. That is, the file goes from A to B, causing it to be reconciled and causing the A->B delta; then resetAST() is called, deleting the old delta and creating an empty delta from B->B. The resetAST() method is called when a compilationParticipant has changed the compilation context, e.g. by generating a new type. For instance, the type being reconciled might have had a reference to a missing type, but performing APT could cause that type to be created, so we want to recompile to see if the missing type reference is fixed. But the file being reconciled is not, itself, allowed to be changed. It is always some other type that is changed or created. So we really don't want to throw out the original delta. Jerome, do you have any thoughts on whether there is another approach to signaling the need to recompile, that would not cause the Java element delta to be discarded?
Thanks for investigating Walter. This is indeed a problem in ReconcileWorkingCopyOperation that forgets the delta when the ast is reset. Taking over as I believe the fix must be done in JDT/Core (I hope you don't mind :-) )
Created attachment 83515 [details] Proposed fix and regression test
Fix and test released for 3.4M4
Wow, thanks for the quick turnaround guys! My problem is solved :)
(In reply to comment #11) > I hope you don't mind :-) Thanks, Jerome. Much appreciated. Happy Thanksgiving, from the USA :-)
Verified for 3.4 M4 using build I20071211-0010.
