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.
RC2 build: 200504261930 I have a class which inherites from some abstract class and interfaces. Steps to reproduce: 1. open a source file of the class and invoke Override methods action 2. select "Show superclasses and interfaces" checkbox 3. select 'Show abstract methods only' checkbox Result: many exceptions were thrown into ide.log, the dialog shows non-abstract methods too.
Created attachment 21892 [details] exceptions' stacktraces
Weird - their is nothing from java modules on the stacktrace. Dan, please evaluate.
BTW: If this is a regression, which build works OK?
probably since 20050413 but i found it is not so easy to reproduce
I have found a reliable way how to reproduce the problem: 1) Create a simple class that extends java.util.AbstractList and implements java.util.Iterator 2) Invoke "Override Methods" action on the class. 3) Check "Show Superclasses and Interfaces". 4) Check "Show Abstract Methods Only". The exceptions attached above are always thrown. It is true that the dialog shows non-abstract methods by this stage, but it is a consequence of the exceptions. If "Show Abstract methods Only" is unchecked and checked again, there are only abstract methods. Seems like a problem with nodes, reassigning to openide for further evaluation.
Reproduced the problem, investigating. Problem either in nodes or in explorer.
I have a "fix" that workarounds the exception in the visualization code (prevent VisualizerChidren from generating inconsistent VisualizerEvents) but some strange incomming data are causing the problem in the first place. I'll keep investigating.
What happens: Let's look at the java.lang.Object Node for the original scenario. It has two methods, "clone()" and "finalize()", and they should be both removed once the user switches to the "abstract only" mode. VisualizerChildren.remove() is called with remList containing (ID hashcodes) [MethodNode@b24c03, MethodNode@1d09ad6], while the children currently holds visualizers for [MethodNode@116b52c, MethodNode@1d09ad6]. That is, there are three different node instances, [A,B], [C,B] The nodes themself are equals() if they represent the same element (an unfortunate feature of ElementNode), so that A.equals(C) == true. All in all, it seems it is a consequence of issue 57769 *** This issue has been marked as a duplicate of 57769 ***
*** Issue 59480 has been marked as a duplicate of this issue. ***
verified duplicate