I was not able to reproduce it with :
Product Version: NetBeans IDE 7.4 (Build 201310012201)
Java: 1.7.0_45; Java HotSpot(TM) 64-Bit Server VM 24.45-b08
Runtime: Java(TM) SE Runtime Environment 1.7.0_45-b18
System: Linux version 3.5.0-41-generic running on amd64; UTF-8; en_US (nb)

.. could you share the whole project with us ? Thanks in advance.

Unfortunately, I cannot share any part of the project. Moreover, I see that behavior only sometimes and I don't know how to reproduce this (but it happens many times to me) - now I cannot reproduce that. I'm not sure if it is connected with WebSocket, SVN, not saved code, compilation errors of one of the classes, multiple projects, 8h of work with NetBeans...

Can you attach your messages.log?

Created attachment 141178 [details]
message.log after unsuccessful renaming/refactoring

I'm still using RC2 version, I'm not sure about NetBeans 7.4 (final), but I have got the same problem in different project.

I was renaming public static void sync() and public static void sync(int node) methods (first class) using CTRL+R to barrier() and barrier(int node) (without touching accessors). That methods are executing other class (second class) methods with the same name, so I also renamed them (so I was doing 4 rename actions in a row). The other class (third class) extends another one and that another one has the same methods implemented.

I was renaming it very fast and at last renaming/refactoring the bug appears.
In the second class the renaming was unsuccessful.
Result of renaming:
  @Override
  public void sync(int... nodes)
was:
  @Override
  public vobarrierync(int nodes)

First and third class look as supposed.

I had the "Apply rename on comments" check box deselected.

Created attachment 141179 [details]
Copy of message.log created just after bug appears (without unnecessary messages)

Additional comment to see more "troubles" with renaming. I've renamed "myNode()" to "myId()" and in one method (in other class, and even in "Test Packages") first occurrence changed "myNode()" to "myId()", but second one changed to "mymyId" (without parentheses).

I've tried to reproduce the problem as described in comment 4, but without any success.

Is it reproducible also for small projects?
Do you use any Annotation processor? (lombok etc...)?

I'm not sure what you mean by "using any Annotation processor", so I think that I'm not using any. In one project (on one computer) I am developing annotation processor, but that project is not using it. On the second computer I am developing something totally different and without connection with first one.
I had clean NetBeans installation even without importing settings from 7.3.

The projects were rather small: one has 29 handwritten classes, but there were autogenerated classes (total 224 *.java files), other one has at total 120 classes (including internal/anonymous classes).

I'm having this problem on a regular basis in the following version:
NetBeans IDE 7.4 (Build 201310111528) (#6523d6792981)

The issue occurs even in small projects and completely corrupts all references to the renamed class. Some indexing must be out of whack when replacing content. 

I observed the following in a project with three classes:

Original code in Main.java:
Display display = new Display();

Refactor->Rename => Display to Display2

New code in Main.java:
Display2y display = neDisplay2ay()


My messages.log does not indicate any errors, but I have attached it to this bug for system information.

Created attachment 142812 [details]
messages.log from build 201310111528

I too get this issue every day.

I'm running Netbeans 8 with all current updates.
Running on Oracle JDK 8, doesn't matter which build.
Windows 7 64 and Ubuntu 12.04 both duplicate the issue.

This is a major defect which causes bad code to stick around since renaming will kill good code. Sometimes even removing method paramaters or changing method names when the return type is what's being renamed.
It's not consistent. There was an entire week where it worked perfect after updating the JDK, then re appeared.

I tried creating a SSCE example to show but it worked flawlessly (as sometimes it does.), which is not what happens in my real world usage.

Got it to break twice on real code.. in the time writing this.

Real world example:

public class PropertyInfo {

using <CTRL>+R, rename to Property, produces this:

Good renames:
DefaultPropertyMap.java (12 references updated OK)
SettingsBase.java (4 references updated OK)

Bad renames:
MutablePropertyMap.java:

What came out:
    void addProperty(Property property);
    void addProperties(Collection<PropPropertyoperties);
    
    void removeProperty(String propertyName);
    void removeProperty(PropertyPropertyy);
    void removeProperties(Collection<PropertyInfoProperty);

Should have been:
    void addProperty(Property property);
    void addProperties(Collection<Property> properties);

    void removeProperty(String propertyName);
    void removeProperty(Property property);
    void removeProperties(Collection<Property> properties);

  Only the first instance was renamed properly.

SettingsNode.java:
    final Collection<Property> properties;

    public SettingsNode(String name, Collection<PropPropertyoperties) {

    properties.stream().forEach((PropertyPropertyy) -> {

  Again, only first intance renamed property.

SettingsFileTest.java:

    public void testAddProperty() {
        Property property = new PropPropertying.class, "testProperty", "test", "Test property");

    public void testRemoveProperty() {
        PropertyPropertyy = new PropertyInfoPropertys, "testProperty", "test", "Test property");

    public void testGetCurrentPropertyValue() {
        PropertyInfo proPropertyPropertyInfo(String.PropertyProperty", "test", "Test property");

        pmap.addProperty(new PropertyInfo(String.clasPropertyop", "test", "StringProperty"));
        pmap.addProperty(new PropertyInfo(Boolean.class, Property", false, "BooleanProperty"));
        pmap.addProperty(new PropertyInfo(Integer.class, "intProperty0, "IntegerProperty"));

First instance renamed OK, then completely mangles the code (including variable names, parameters, instantiation, etc..

The last three change the names in a String literal, mangling the variable.

SettingsMapTest.java:
        pMap.addProperty(new Property(String.class, "property1", "no", "none"));
        pMap.addProperty(new PropPropertyeger.class, "property2", 127, "none"));
        pMap.addProperty(new PropertyProperty.class, "property3", true, "none"));
        
Again, first is OK, the rest completely mangled.


This is a simple example - but the cleanup takes longer than it would to just do a find/Replace in project - if the output were consistent then cleanup !


The following *always* hold true:
If a file is mangled - the following trend holds:

--------------------------
I have noticed a consistincy in the problem for the shown example:

Input:
PropertyInfo -> Property

Output would be like this:
(In order of usage occuring in the file, and starting where 'PropertyInfo' is in code) 
Property property);
PropPropertyoperties);
PropertyPropertyy);
PropertyInfoProperty);

or:

Property property
PropPropertying.class
PropertyPropertyy
PropertyInfoPropertys, 
PropertyInfo proPropertyPropertyInfo(String.PropertyProperty", "test", "Test 
PropertyInfo(String.PropertyProperty",
PropertyInfo(String.clasPropertyop", "test", "StringProperty"));
PropertyInfo(Boolean.class, Property", false, "BooleanProperty"));
PropertyInfo(Integer.class, "intProperty0, "IntegerProperty"));

The beginning of the output consistently moves over by 4 characters, then replaces the full length of th old name, mangling everything in it's path.


Input:
SettingsBase -> DiskPersistedSettings

One file unscathed - perfect refactoring (but there was only one useage)

The other output like this (in order of code appearance):

was:
import com.rovlab.settings.DiskPersistedSettings; 

became:
import com.rovlab.settings.DiskPersistedSettings; 

was:
public class PendantSettings extends SettingsBase implements JoystickSensitivitySettings, JoystickTrimSettings {


public class PendantSettingsDiskPersistedSettingstingsBase implements JoystickSensitivitySettings, JoystickTrimSettings {

PendantSettings extends SettingsBase 
PendantSettingsDiskPersistedSettingstingsBase

^ no idea how it mangled that..

*** This bug has been marked as a duplicate of bug 243751 ***