I posted a blog post from JavaOne where i stated:  "I did try out several of [Netbean's] refactorings, and was pleased with them for the most part.  However, i tried a rename refactoring that changed the meaning of my code, and they did no verification of the rename to detect and warn me about this.  This makes refactorings highly suspect and dangerous and is definitely something that needs to be addressed asap."

I then received a message from PDeva who says: "Could you give us an example of the rename refactoring that changed the meaning of the code? ... just curious to know whether i screwed up my code accidentally while using the netbeans refactoring."

PDeva: Absolutely.  Here we go.

Let's start with the following simple code sample:

class C {
int a; //rename a --> b

void F() {
int b = 0;
int c = a;
}
}
Now, as you can tell, if you go ahead and just blindly rename all the symbols that reference the 'a' field, you're going to end up with a problem.  Specifically:
class C {
int b;

void F() {
int b = 0;
int c = b; //uh-oh, 'b' now refers to the local, not the field
}
}
The is an example of a conflict that you need to detect and make the user aware of.  Of course, this is addressable.  Refactoring tools could be smart and instead change the code into:
class C {
int b;

void F() {
int b = 0;
int c = this.b; //Now everything is fine.
}
}
However, we don't provide this sort of workaround. Because of certain architectural choices we made, it can make certain things difficult if we change the number of tokens in a file in the middle of a refactoring.  In the future i'd like for us to provide these sort of "fixes" to allow the refactoring to continue while still preserving the meaning of your code.  However, it's not always the case that there is a way to work around such a conflict, and so it is important to tell the user about these problems.

Why is it important? Well, if we look at Martin Fowler's Refactoring Site, we'll find the following information:
Q: What is Refactoring?
A: Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.
However, in the above examples if we blindly change 'a' to 'b' we're violate the requirement that external behavior is not changed. 

If you use Netbeans3.1 then you'll the IDE willingly transform the code from:

into    Ack!
However, with Visual Studio and Eclipse you will get:
  or 

This will allow the user to know that the refactoring will most likely not be doing what they were expecting and will ensure that they don't accidently change the meaning of their code.