Question

I’m having problems with the NetBeans Nodes API.

I have this line of code:

Node n = (new MyNode(X)).getChildren().getNodeAt(Y);

The call to new MyNode(X) with the same X always initializes a MyNode the same way, independent of the context.

When I place it by itself (say, in an menu action), it successfully gets the Yth child, but if I put it in an event where other Node/Children stuff happens, it returns null.

MyNode’s Children implementation is a trivial subclass of Children.Keys, which is approximately:

// Node
import org.openide.nodes.AbstractNode;

class MyNode extends AbstractNode {

    MyNode(MyKey key) {
        super(new MyNodeChildren(key));
    } 
}


// Children 
import java.util.Collections;
import org.openide.nodes.Children;
import org.openide.nodes.Node;

public class MyNodeChildren extends Children.Keys<MyKey> {
    MyKey parentKey;

    MyNodeChildren(MyKey parentKey) {
        super(true); // use lazy behavior
        this.parentKey = parentKey;
    }

    @Override
    protected Node[] createNodes(MyKey key) {
        return new Node[] {new MyNode(key)};
    }

    @Override
    protected void addNotify() {
        setKeys(this.parentKey.getChildrenKeys());
    }

    @Override
    protected void removeNotify() {
        setKeys(Collections.EMPTY_SET);
    }
}

// MyKey is trivial.

I assume this has something to do with the lazy behavior of Children.Keys. I have the sources for the API, and I’ve tried stepping through it, but they’re so confusing that I haven’t figured anything out yet.

NetBeans IDE 7.0.1 (Build 201107282000) with up-to-date plugins.

Edit: More details

The line with the weird behavior is inside a handler for an ExplorerManager selected-nodes property change. The weird thing is that it still doesn’t work when the MyNode instance isn’t in the heirarchy that the ExplorerManager is using (it’s not even the same class as the nodes in the ExplorerManager), and isn’t being used for anything else.

Accessing the nodes instead of the underlying model is actually necessary for my use case (I need to do stuff with the PropertySets), the MyNode example is just a simpler case that still has the problem.

Answer 1

Timon Veenstra on the NetBeans Platform Developers mailing list solved this for me.

Actions on the explorerManager are guarded to ensure consistency. A
node selection listener on an explorer manager for example cannot
manipulate the same explorer manager while handling the selection
changed event because that would require a read to write upgrade. The
change will be vetoed and die a silent death.

Are you adding the MyNode root node to the explorer manager on
initialization, or somewhere else in a listener?

My problem line is in an ExplorerManager selection change listener. I guess the Children.MUTEX lock is getting set by ExplorerManager and preventing the Children.Keys instance from populating its Nodes…?

Anyways, I moved my Node access into a EventQueue.invokeLater(…), so it executes after the selection changed event finishes, and that fixed it.