Bug 4270 - Rename refactorings are broken (1GKRF37)
Summary: Rename refactorings are broken (1GKRF37)
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 2.0   Edit
Hardware: All Windows 2000
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Dirk Baeumer CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2001-10-10 23:08 EDT by Dirk Baeumer CLA
Modified: 2002-02-08 03:07 EST (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dirk Baeumer CLA 2001-10-10 23:08:55 EDT
Create the following class
public class A {
		public int fCounter;
		
		public void init() {
			fCounter= 10;
		}
}

Select the field fCounter in the outliner and rename it to fCounter2.
Presse Finish on the wizard.

==>> the file seems ok but the outliner still shows fCounter

Close the file
Reopen it

==>> the references are updated but the declaration is still fCounter. I think 
the document and the compilation unit got
somehow out of sync.

The same happens for Rename type. I didn't test other renames, but I think they 
reveal the same problem.

Suggestion: this has something to do with the possibility to run a refactoring 
without updating references.

NOTES:


DB (28.09.2001 16:27:48)
The problem is that we create two different change objects for the same CU. The 
current document provider can't
handle the case where I call save to times without having a full aboutToChange
(), save(), changed() cycle. 
Having two change objects leads to the cycle aboutToChange(), save(), 
aboutToChange(), save(), changed(), changed().

To get rid of the whole problematic I opt to implement out own line aware text 
buffer which directly manipulates the 
working copies IBuffer.
Comment 1 Dirk Baeumer CLA 2001-11-09 06:28:01 EST
New text infrastructure implemented.