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.
[dev mar 06] If a bean has a BeanInfo giving an IndexedPropertyDescriptor giving only an indexed getter and no other accessors, BeanNode.computeProperties creates an IndexedPropertySupport for the property, where valueType==null. This is illegal according to the IndexedPropertySupport Javadoc, which does not mention that a null param is OK. (Actually it does not mention that *any* null params are OK, which is probably a docs bug. All params which might be null must be documented as such.) IndexedPropertySupport passes the null valueType to Node.IndexedProperty, which again is not documented to accept it. Node.IndexedProperty passes the null to Node.Property, which is also not documented to accept it (nor is getValueType documented to return it). And Node.Property.hashCode (as well as other methods) assume that it is not null. For an example, see issue #21284, where a poorly written BeanInfo for the Sun-style XML catalog resolver (Runtime | XML Entity Catalogs | Resolver at file:/whatever) produces such an IndexedPropertyDescriptor. If you select a range of such resolvers in the Explorer, the property sheet tries to merge their properties, thus using a hashtable, thus calling Node.Property.hashCode, thus causing an NPE. P2 because not only is an exception thrown, but almost anything you do in the IDE will continue to throw more NPEs until you exit.
Created attachment 4976 [details] Stack trace
Node.Propert and Node.IndexedProperty are rewritten to handle the null values in valueType and elementTypeCorrectly. For regression test please see: openide/test/regr/srcorg/openide/nodes/BeanNodeBug21285.java
OK. The Javadoc comments for several classes are still wrong, then.
*** Issue 22497 has been marked as a duplicate of this issue. ***
verified
Verified in Update patch 2 for S1S 4.1
Resolved for 3.4.x or earlier, no new info since then -> closing.