This bug appears to be only on Solaris 8. I can reproduce this
consistently using JDK 1.4 FCS with all patches installed.

Chris, can you reproduce this bug in latest dev builds or in NB 3.3.1?
We cannot reproduce it here...
Thanks

Cannot reproduce even on Solaris 8 machine, JDK-1.4.1 + all patches.

Created attachment 5363 [details]
Here is the result of the test case specified in the report

This problem still happens consistently on Solaris 8, using JDK 1.4
(with all required os patches). I attached a screen shot of the
resulting explorer view. This problem also happens consistently for a
colleague using the same os and jdk. If there are any diagnostics
which would be helpful in diagnosing this problem, please attach to
bug report.

The attached image shows the problem when rename was used on the
test234 java class element. As you will notice, the class element and
the file have a different name. 

Chris, if the package declaration of test234.java is not correct,
ClassElementNode is not renamed. Are you sure, that package
declaration of test234.java is "package something.b12345" ?
Thanks

I am positive that the package declaration is correct. I can replicate
the test by create a new class, then selecting the ClassElementNode
and executing the rename action. 

I looked in the directory containing the java file and the file has
been renamed correctly. The explorer view is not updated properly. 

I verfied this by executing the following using internal execution:
   try {
        ClassElement ce = ClassElement.forName("b12345.t2345");
        ce.setName(Identifier.create("t23456"));
        ce = ClassElement.forName("b12345.t23456");
        System.out.println(ce);
        } catch (SourceException se) {}

Not fixed yet. Changing milestone to 3.4. To be moved back as soon as
fixed.

x 

Chris, your last comment suggests that the file 
name/classname are both correct - only the visuals of the 
file node hasn't beed updated. Is that true ? [we may be 
looking into wrong part of the code all the time :-)] 

Created attachment 5395 [details]
Patch jar printing diagnostic messages

I've attached a patch jar; please put it into directory 
modules/patches/org-netbeans-modules-java/ 
under your IDE installation. It's quite noisy :-) 
 

Here is the output during the rename operation. The rename is
performed on the ClassElementNode, however, the explorer view still
reflects the c2 original name. In the filesystem the filename is
c3.java as expected.

Class name change (c2->c3
main class: c3, file=c2
[rescan-start]
found main class: c3
[rescan-end]
primaryFileMoved: c3->b12345/c3.java
[rescan-start]
found main class: c3
[rescan-end]

The display following the rename is
c2.java
  class c3

As a side note: The diagnostic patch was displaying messages about
internal ide classes such as 
[rescan-start]
found main class: EntJavaBeanImpl
[rescan-end]
[rescan-start]
found main class: WeblogicServerInstanceNode
[rescan-end]
[rescan-start]
found main class: LCTest
[rescan-end]
[rescan-start]
found main class: i18n
[rescan-end]

Why would this classes appear here? 

I tried another execution this time renaming at the top level node
(not the ClassElement). This was immediately following the c2-c3
rename. The logging information:

[rescan-start]
[rescan-end]
primaryFileMoved: c4->b12345/c4.java
Class name change (c3->c4
main class forgotten or invalid ?, rescanning.
[rescan-start]
found main class: c4
[rescan-end]
[rescan-start]
found main class: c4
[rescan-end]

This leaves the node name and the class name in synch as expected.

OK, so (once again to be sure). If the error happens, then the file on
the disk has the correct name, but the display in the explorer is
wrong. If so, I'll move the diagnostic into the DataObject part. Do
you have file extensions visible in your Explorer ?

Yes, your assessment is correct the file on disk matches the
ClassElementNode, but the top level node is different. Also, I am
displaying file extensions.

At least I reproduced it (once) - the key is to turn on file extension
display. Everything, including name property of the java source node
is updated, but not the display name.

I hate to reassign bugs without a patch... but here's what  
I've found:  
The JavaNode (represents the whole source file), NOT the  
ClassElementNode ("class XXX") retains the obsoleted name.  
To reproduce:  
- start a fresh build  
- turn "Show File Extensions" in Tools | Options | IDE  
Settings | System to True  
- drill down to some public class node (e.g.  
examples/advanced/MemoryView.java -> class MemoryView)  
then do a rename of the class.  
  
During debugging, I found out that the  
AbstractNode.setName() avoids setting displayName  
property, while firing PROP_DISPLAY_NAME change event.  
That works when file extensions are off, setDisplayName()  
calls are passed the value of getName() ==  
getPrimaryFile().getName() and Node.setDisplayName() finds  
this out and does nothing, leaving null (== use getName())  
as the display name value.  
  
I would recommend to call DataNode.updateDisplayName()  
from within PROP_NAME handler attached to DataObject  
(inside DataNode.fireChange) - but I'm not sure about side 
effects. 

yarda, please help us with this bug.  harmernik is on vacation

x

Svata, thanks for your thorough analysis and the suggested fix.  I've
committed into the CVS trunk.  

DataNode.java rev 1.69

Verified in the trunk.

merged into orion_fcs

verified in Orion too

Resolved for 3.4.x or earlier, no new info since then -> closing.

Integrated into 'main-golden', will be available in build *201204260400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/93ab0a7b0668
User: Jaroslav Bachorik <yardus@netbeans.org>
Log: #21677: Do not hard-wire dependency on "dist" target when generating profiler targets