This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
When invoking code like the example below, multiple times within a RequestorProcessor.Task, I encountered problems with constructors failing to update. ClassElement ce = ...; DataObject dObj = (DataObject) clsElem.getSource ().getCookie (DataObject.class); if (dObj != null) { dObj.getNodeDelegate().setName(newName); } I introduced some print statements to attempt to determine where the problem was and traced the behavior to org.openide.src.ClassElement, which is invoked from the updateSource method of JavaDataObject. What appears to be happening is that the # of constructors is 0 when the updateConstructorsNames method is invoked, so the old constructors are not being modified. This method is actually invoked from the MemberElement.setName method, which first invokes getMemberImpl().setName and then invokes updateConstructorsNames method in ClassElement. I didn't trace the problem deeper into the Impl classes, but the getConstructor method appears to filter the methods based on class name to calculate the constructor set, so the act of changing the class name appears to alter this process (this seems to have some asynchronous behavior which is why it doesn't always happen). I am including the diffs for MemberElement and ClassElement which seem to fix this problem; however, I am unsure what affect the changes would have on other items. cvs diff -w ClassElement.java Index: ClassElement.java =================================================================== RCS file: /cvs/openide/src/org/openide/src/ClassElement.java,v retrieving revision 1.61 diff -w -r1.61 ClassElement.java 229a230 > updateConstructorsNames(name); bling% cvs diff -w MemberElement.java Index: MemberElement.java =================================================================== RCS file: /cvs/openide/src/org/openide/src/MemberElement.java,v retrieving revision 1.21 diff -w -r1.21 MemberElement.java 90c90 < updateConstructorsNames(name); --- > // updateConstructorsNames(name);
Reassigning to java
Hmm. I will probably need a test program that does exhibit the bug at least sometimes, since I am not able to reproduce what you describe. In fact, I wonder how it is possible that your patch really works, because the java module's implementation throws an exception, if somebody tries to set constructor's name to something other than the current class' name - which your patch does, since it first tries to update constructors and then sets the class' name itself. As for the implementation: constructors are kept separately from methods, but parser really recognizes them by name. I suspect some kind of race condition between the parser updating model in the background and inherently non-atomic update of all the names, but I need to find out where exactly the race is to fight it. BTW lowering priority to P-3 because of bad reproduction conditions. It works in most cases even in automated tests that explicitly look for code consistency.
I was able to reproduce the bug consistently with the patch below. The patch introduces a longer time between changing the name of the class and rename of the constructors (to test the atomicity). I had several existing java classes with one or more constructors other methods and field. I then restarted the ide with the patch. Next I simply selected the nodes and used the rename action. After a while, the nodes will show up with the error icon as the constructors have not been renamed. Patch to reproduce the problem: cvs diff -w MemberElement.java Index: MemberElement.java =================================================================== RCS file: /cvs/openide/src/org/openide/src/MemberElement.java,v retrieving revision 1.21 diff -w -r1.21 MemberElement.java 89a90,93 > try { > Thread.sleep(5000); > } catch (InterruptedException e) { > } P.S. I had to file the original bug report as P1 because there is a P1 bug filed against our module that has this as the root cause.
I hate to say it, but even this patch didn't make the bug occur on my machine. However, as I said - the change is really NOT atomic right now, since it happens outside of thread-safe implementation (in the openide, actually). I'm moving the update logic inside model implementations (both memory and java module).
Although I failed to reproduce the bug, the patch helped me discover a potential race condition with parser and other thread competing for source. But, some code must order the parser to update data even if it encounters errors. This is done when/after doc state changes (open, close), save or similar operations.
[release32-20] Verified. Chris, if this bug still bothering you, please reopen.
Target milestone -> 3.2
Resolved for 3.4.x or earlier, no new info since then -> closing.