Community
Participate
Working Groups
3.5M7 Steps: 1. select two Java files in PE and do Compare With > Each Other 2. toggle breakpoint in StructureCreator.createStructure(Object, IProgressMonitor). 3a. edit left side => observe that createStructure is called twice for the left element 3b. edit right side => observe that createStructure is called once for the left element and once for the right element
Missed one step that should go between 1 and 2: - Open the file from the left side in a separate CU editor or - Open the file from the right side in a separate CU editor to get an opposite result: => createStructure is called twice for the right element when editing right => craeteStrucute is called once for the left element and once for the right element when editing left
Dani is this an expected behavior?
>Dani is this an expected behavior? It should not happen but I can imagine the cause for this: compare probably does not disable the reconciler when it gets deactivated (i.e. the Java editor activated) and hence two reconcile take place and acted upon. The code which does this is in JavaReconciler but of course it expects that the Java editor is the top level part and can't handle nesting.
You're right. Here is the stack: Daemon Thread [org.eclipse.jdt.internal.ui.text.JavaReconciler] (Suspended (breakpoint at line 171 in StructureDiffViewer$StructureInfo)) StructureDiffViewer$StructureInfo.getRefreshTask() line: 171 JavaStructureDiffViewer(StructureDiffViewer).contentChanged(IContentChangeNotifier) line: 401 JavaStructureDiffViewer.elementChanged(ElementChangedEvent) line: 258 DeltaProcessor$3.run() line: 1557 SafeRunner.run(ISafeRunnable) line: 42 DeltaProcessor.notifyListeners(IJavaElementDelta, int, IElementChangedListener[], int[], int) line: 1547 DeltaProcessor.fireReconcileDelta(IElementChangedListener[], int[], int) line: 1399 DeltaProcessor.fire(IJavaElementDelta, int) line: 1358 ReconcileWorkingCopyOperation(JavaModelOperation).run(IProgressMonitor) line: 769 ReconcileWorkingCopyOperation(JavaModelOperation).runOperation(IProgressMonitor) line: 788 CompilationUnit.reconcile(int, int, WorkingCopyOwner, IProgressMonitor) line: 1242 JavaReconcilingStrategy.reconcile(ICompilationUnit, boolean) line: 126 JavaReconcilingStrategy.access$0(JavaReconcilingStrategy, ICompilationUnit, boolean) line: 108 JavaReconcilingStrategy$1.run() line: 89 SafeRunner.run(ISafeRunnable) line: 42 JavaReconcilingStrategy.reconcile(boolean) line: 87 JavaReconcilingStrategy.reconcile(IRegion) line: 151 JavaCompositeReconcilingStrategy(CompositeReconcilingStrategy).reconcile(IRegion) line: 86 JavaCompositeReconcilingStrategy.reconcile(IRegion) line: 102 JavaReconciler(MonoReconciler).process(DirtyRegion) line: 77 AbstractReconciler$BackgroundThread.run() line: 206 In case when the createStructure is called for both sides reconcile is done for two different documents. I didn't get the part about deactivating compare. These doubled calls happen when editing in Compare Editor, so it supposed to be active.
>These doubled calls happen >when editing in Compare Editor, so it supposed to be active. Right. Should have read all details.
In case when createStructure is called twice for the same element (editing B.java in Compare Editor, compared with A.java and having B.java open in another editor), ElementChangedEvent events are slightly different: - [Working copy] B.java[*]: {CONTENT | FINE GRAINED | AST AFFECTED} - [Working copy] B.java[*]: {AST AFFECTED} And when called for both elements (editing A.java in Compare Editor, compared with B.java and having B.java open in another editor), the events are : - [Working copy] A.java[*]: {CONTENT | FINE GRAINED} - [Working copy] B.java[*]: {AST AFFECTED}
Patch from bug 275286 fixes this issue as well. Again, code change is completely on JDT side.
See the comment above. This bug has exactly the same cause as bug 275286. *** This bug has been marked as a duplicate of bug 275286 ***
