Community
Participate
Working Groups
Build id: N20090110-2000 Steps: 1) Create a java project and two classes inside (A.java and B.java). They can be very simple, e.g. public class A { // class A } 2) Compare them using Compare With > Each Other 3) In the compare editor, change something in A.java, e.g. // comment public class A { // class A } 4) Double click on a node in the structure view 5) Notice that the content of the viewer with A.java changed to // comment public class A { // 6) Save, still the content is wrong 7) Open A.java in the java editor, it looks ok
Sorry, cannot reproduce it on N20090121-2000. Could check if these steps still don't work for you?
Szymon is out of the office, we will try to reproduce these steps when he gets back.
It's crucial not to save between 3) and 4).
I'm sorry, but this will have to deferred to 3.5 M7. The good news is that this will be on top of my list.
The issue we're dealing here with is caused by the fact that in 4) we're opening DocumentRangeNode (JavaNode in fact) which a Range/Position not update with the change made in 3). For instance, if in 4) you double clicked on A node (Java class) but in 3) you'd added "// comment" the new range returned for the node should be Position(oldOffset+10, oldLength). 10 is length of "// comment" string. This ain't happening now, so when asked for the range/position again you'll get Position(oldOffset, oldLength). I need to find out why JavaNode's passed from JavaStructureDiffViewer are "outdated".
It appears that Dani's Example code submitted on bug 165434 may be a possible solution for this issue. It listens to content changes and updates structures in the Structure Diff Viewer. I will hold off with marking this one as dependent and take a closer look at what Dani proposed in the mentioned bug.
Even though a fix to bug 165434 looks promising, I still wonder what kind of event triggered structure updates prior Java enhanced compare...
Apparently this is caused by bug 193324, which replaced ResourceCompareInput with SaveablesCompareEditorInput. RCI when asked to adapt to IFile.class[1], which happened on focus changes, action updates etc, flushed viewers. Flushing resulted in content being changed, thus refreshing the structures. The above revealed that even without fixes made in bug 193324 and bug 169386, using an input different than RCI, for instance when comparing a local file with a remote revision the structure view would break the same as described in comment 0. This means that this bug is not necessarily a regression. imo, bug 193324 and this one uncovered an issue that has existed for a long time. [1] org.eclipse.compare.internal.ResourceCompareInput.getAdapter(Class)
Szymon, I'm having trouble to reproduce this. Can you provide a step by step test case that shows the issue?
Steps: 1) Start an empty workspace 2) Create java project "javaProject1" 3) In the default package, create A.java public class A { // class A } 4) In the default package, create B.java public class B { // class B } 5) Compare them using Compare With > Each Other 6) In the compare editor, modify A.java to have // comment public class A { // class A } and DON'T SAVE 7) Double click on A node in the structure view 8) Notice that the content of the viewer with A.java changed to // comment public class A { // I'm attaching a screenshot illustrating the issue.
Created attachment 131780 [details] Screen shot
Sorry, I got confused by comment 3 when reading to fast over the bug: I probably saved because in comment 0 nothing is written about save and in comment 3 I read "save". Anyway, I can reproduce now.
Created attachment 132239 [details] Patch v01 The simplest solution: react to any changes that affect a matching Java element.
Created attachment 132240 [details] mylyn/context/zip
Created attachment 132614 [details] Patch v02 A more appropiate approach with modified check that looks for any content changes instead of possible structural changes only. And again, the fix doesn't contain any changes in o.e.compare so it will need someone from JDT to review it. Dan,i it would be great if I could hear your opinion about it.
The patch works but it is not so good regarding performance: with this change we create an AST on each textual change. There's no easy workaround for this however, except 1) using the shared AST where possible ==> filed bug 273454 2) only use the AST if needed (most of the information is in the Java model) ==> filed bug 273455 Committed simplified version of the patch to HEAD. Available in builds > N20090422-2000.
