Nodes are presentation objects. They have actions, properties and localized display names - they are the place where the architecture meets the human. Nodes typically wrap some model object and provide human-readable names, icons, etc. They are at the heart of a lot of NetBeans selection and user interface systems.

Nodes are a generic tree structure. A common use for them is to display DataObject s to the user - to represent the user’s files visually. Each node has a Children object that can supply a list of child nodes. Nodes are not visual components, and they do not subclass TreeNode from the JDK - they are more related to the JavaBeans specification, subclassing java.beans.FeatureDescriptor.

Nodes are displayed in explorer views. The Explorer API provides a number of Swing components which take a Node and can display that node and its children - in trees, lists, tree tables, etc. The property sheet is also an Explorer view - Nodes have properties, which are key-value pairs with localized names.

Generally Nodes should represent not be the objects the user is interacting with - if you are putting huge amounts of logic in your Node class, you’re probably doing something wrong.

Nodes form the basis of global selection in NetBeans - each component in a tab in the ui has an "activated Node". The system globally tracks what component has focus, and each component typically offers some node as the currently selected node (which can change when the user clicks, etc.).

A Node has a Lookup which you can ask for objects your code is actually interested in. You never get the selected node and then cast it to some specific Node subclass and do things to that; the real model objects should be available from the Node’s Lookup. This helps to future-proof your code - you can have another module provide the same objects your client code is interested in from its` Node’s lookup, and the client code never has to change - it’s just looking for any Node that has what it needs.

Read about how to implement your own Nodes