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.
This is a 4.0-type architectural cleanup request. Currently for classes inheriting from FeatureDescriptor, there are basically two ways to provide special behavior for name (displayName, shortDescription): 1. Call setName (setDisplayName, ...) whenever you like. 2. Override getName (...) to return the currently correct value, and call fireNameChange (...) when that value would become different. A similar situation applies to AbstractNode.setIconBase vs. getIcon. As mentioned in the message to dev@openide (see URL), I believe approach #2 is much more maintainable when subclassing is a possibility, and thus that approach #1 should be deprecated, e.g.: 1. Deprecate Node.setName etc. in Javadoc. And/or produce runtime warnings. 2. Request existing subclasses of Node to override getName (...) where dynamic behavior is needed. Include this request in an upgrade guide. Specifically, change DataNode's behavior with the showFileExtensions flag: DataNode should only override getName (never call setName), and its impl should compute the name based on DataObject.name, showFileExtensions, and the FileSystem.Status annotations. The node for DefaultDataObject would behave similarly but treat showFileExtensions as always on. (Perhaps showFileExtensions should be deprecated and reimplemented somehow because it is ugly, but I do not have a proposal here.) 3. It would be unfortunate to require someone to subclass AbstractNode (e.g.) just to be able to set the name, where currently they do not! So provide a new API call similar to the situation with AbstractLookup and InstanceContent: 3a. A new class (?) holding basic bits of Node information such as name, displayName, shortDescription, iconBase; public getters and setters for them. 3b. A constructor for AbstractNode accepting an object of this class. If you actually make the AbstractNode, you can hold onto an instance of this controller and change its name, without subclassing the node itself. If you did not make the node, you cannot change its name etc. - i.e. the "setters" are effectively protected, with public getters - since the AbstractNode provides no way to get the controller once created. 3c. Constructors accepting this controller object for other nodes in the APIs which extend AbstractNode and which do not normally provide dynamic naming (or icon) behavior, and for which it is likely that someone would want to configure the name. I am not sure of any examples offhand however. 3d. Other subclasses of Node or AbstractNode should decide whether to override getName (...) and if so whether to make the override final; or to avoid overriding getName (...) and instead provide a constructor with the controller object; or something else along these lines.
Some relevant bugs caused by, or whose solution was made more complex by, the mixing of set-style vs. override-style idioms, are listed in the "blocks" area here. I will add more if I remember any. Also cf. DataNode.java 1.52 which seems to be similar.
I see that AbstractNode.setPreferredAction was introduced in 3.5 along with a nonfinal getPreferredAction. This is unfortunate (see issue #32744 for some problems it contributes to). Is it too late to delete the setter method before 3.5 is released?
Taking over the node bugs from phrebejk.
Reassigning to new module owner Tomas Holy.
Too late. According to our compatibility policy I would need to go through all our sources and clean them up. I am not going to do that.