TreeCellEditor and isCellEditable method

Question

I'm confused about how to handle tree cell edits. See the example program below. As you click around the tree, note that the isCellEditable method is called on the cell you are leaving, and not on the cell you are going to. This causes the cell you are going to to be rendered with the editor of the cell you are coming from. There is something I'm missing. What is it?
What I thought would happen:
1) isCellEditable called on cell you are going to
2) if isCellEditable returns true, the editor is used to render the cell, otherwise the renderer is used.
What is happening:
1) isCellEditable called on the cell you are coming from. (perhaps this test is done to see if valueForPathChanged should be called on the model?)
2) ????
Example code:
public class TestTreeCellEditor extends AbstractCellEditor implements TreeCellEditor {
     private JLabel label = new JLabel();
     @Override
     public Component getTreeCellEditorComponent(JTree tree, Object value,
               boolean isSelected, boolean expanded, boolean leaf, int row) {
          label.setText(((DefaultMutableTreeNode) value).getUserObject().toString());
          return label;
     @Override
     public Object getCellEditorValue() {
          return label.getText();
     @Override
     public boolean isCellEditable(EventObject e) {
          TreePath path = ((JTree) e.getSource()).getSelectionPath();
          if (path != null) {
               DefaultMutableTreeNode node = (DefaultMutableTreeNode) path.getLastPathComponent();
               String nodeText = node.getUserObject().toString();
               System.out.println("Testing node with text \"" + nodeText + "\"");
               return nodeText.indexOf("NOT") < 0;
          return false;
public class TestTreeEditBehavior {
     public static void main(String[] args) {
          SwingUtilities.invokeLater(new Runnable() {
               public void run() {
                    launchUI();
     private static void launchUI() {
          JFrame frame = new JFrame("Test Tree Edit Behavior");
          DefaultMutableTreeNode root = new DefaultMutableTreeNode("NOT Editable");
          root.add(new DefaultMutableTreeNode("I'm editable."));
          root.add(new DefaultMutableTreeNode("Me too!  I can be edited."));
          DefaultTreeModel model = new DefaultTreeModel(root);
          JTree tree = new JTree(model);
          tree.setCellEditor(new TestTreeCellEditor());
          tree.setEditable(true);
          JPanel panel = new JPanel();
          panel.add(tree);
          frame.setContentPane(panel);
          frame.pack();
          frame.setLocationRelativeTo(null);
          frame.setVisible(true);
}What I expect to happen and what actually happens are obviously not the same. What am I supposed to be doing?

Answer 1

Okay...here is how it looks to me:
What happens when you need to write your own custom TreeCellEditor?
TreeCellEditor requires the following methods:
    public abstract Component getTreeCellEditorComponent(JTree jtree, Object obj, boolean flag, boolean flag1, boolean flag2, int i);
    public abstract Object getCellEditorValue();
    public abstract boolean isCellEditable(EventObject eventobject);
    public abstract boolean shouldSelectCell(EventObject eventobject);
    public abstract boolean stopCellEditing();
    public abstract void cancelCellEditing();
    public abstract void addCellEditorListener(CellEditorListener celleditorlistener);
    public abstract void removeCellEditorListener(CellEditorListener celleditorlistener);However, you can probably get away with AbstractCellEditor handling most of the work. With AbstractCellEditor extended, you then only need to implement two methods:
    public abstract Component getTreeCellEditorComponent(JTree jtree, Object obj, boolean flag, boolean flag1, boolean flag2, int i);
    public abstract Object getCellEditorValue();However, you may still want to override some of the methods AbstractCellEditor handles for you. For example, AbstractCellEditor always returns true from the isCellEditable method. If you cells are not always editable, you will want to override this method.
You will note, however, using AbstractCellEditor you lose certain things provided by the DefaultTreeCellEditor. For example, fields are edited automatically on selection (if editable) rather than using the more complex behavior of the DefaultTreeCellEditor (triple-click or click-pause-click), and icons for the tree will be missing. You can reimplement this behavior on your own, but there is a potentially better approach. One of the DefaultTreeCellEditor constructors takes a TreeCellEditor as an argument. Pass your custom TreeCellEditor to this constructor, and you get the DefaultTreeCellEditor behaviors back (assuming you didn't already override them).
More about isCellEditable
When you ask whether or not a cell is editable, you are really asking two questions:
1) Is the cell editable?
2) Should the editor be activated given the user actions? (e.g. double-click, triple-click, etc)
Your cell editor should answer question 1 (AbstractCellEditor always returns true). The DefaultTreeCellEditor answers question 2. If you do not use the DefaultTreeCellEditor, then you should also answer question 2.
An odd happenstance of the DefaultTreeCellEditor is it's click-pause-click behavior to activate the editor. When this happens, the second click causes isCellEditable to be called again with a null EventObject (at least with Java 1.6.0_20-b02). If we assume this is the only time the EventObject will be null, you should probably just return true when the EventObject is null. Unless you wanted to specifically disable the click-pause-click behavior, in which case you could return false. But either way, make sure you check the EventObject for a null value.