JDK-8090563 : Tree/Item/ModificationEvent: must fully support list changes
  • Type: Enhancement
  • Component: javafx
  • Sub-Component: controls
  • Affected Version: 8u40
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2014-12-10
  • Updated: 2020-06-26
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
missing support:

- changes with subchanged (f.i. discontinous removes/adds)
- permutations

Without, there's no way interested client code can keep state related to current locations of items. Examples of how internal code suffers from the omissing is selectedIndices/selectedItems of TreeView. (Which currently might not be claringly obvious because all internal implementations of selection models are incorrect in respect to multiple subchanges, tree selection bugs show the same symptoms). While the list-based models can be implemented correctly (see f.i. IndicesList/IndexedItems in my git), the tree-based can't.

Some pseudo-code snippets:

    // expect a single notification because ...
    @Test
    public void testChildEventDiscontinousRemoved() {
        IntegerProperty p = new SimpleIntegerProperty(0);
        EventHandler<TreeModificationEvent> l = e -> {
            assertTrue(e.wasRemoved());
            p.set(p.get() + 1);  
        };
        treeItem.addEventHandler(TreeItem.childrenModificationEvent(), l);
        children.removeAll(children.get(2), children.get(5));
        assertEquals("received singe removed", 1, p.get());
    }

    // without single notification can't safely update stored indices
    @Test
    public void testChildEventSubChanges() {
        // simulate external storage of last index
        IntegerProperty p = new SimpleIntegerProperty(children.size()-1);
        EventHandler<TreeModificationEvent> l = e -> {
            assertTrue("sanity: got a removed", e.wasRemoved());
            // adjust index: fine for single subChange
            p.set(p.get() - e.getRemovedSize()); 
            // this must be valid but isn't because it's the first
            // of a sequence of separate notifications
            children.get(p.get());
        };
        treeItem.addEventHandler(TreeItem.childrenModificationEvent(), l);
        children.removeAll(children.get(2), children.get(5));
    }

    // no way to update index-based state after sorting
    @Test
    public void testChildEventPermutated() {
        EventHandler<TreeModificationEvent> l = e -> {
            assertTrue("sanity: got a permutated", e.wasPermutated());
            // now how to get the permutation indices?
        };
        treeItem.addEventHandler(TreeItem.childrenModificationEvent(), l);
        Comparator<TreeItem<String>> c = (TreeItem<String> o1, TreeItem<String> o2) 
                -> o1.getValue().compareTo(o2.getValue());
        children.sort((Comparator<? super TreeItem>) c);
    }
    

Comments
degree of bugginess changing JDK-8096243 - added a public constructor taking the Change and (partly) used it in selectionModel JDK-8094602 - removed that public constructor, making it not accessible for custom treeItems/selectionModel (can only rely on dirty reflective access) Also, TreeModificationEvent is still over-ruling change's notion of wasPermutated (see my comment to JDK-8199324) - that's a no-no-ever, IMO. Both list and selectionModel might have their own ideas on it, but certainly not the messenger (that is the TreeModificationEvent) Updating an old summary on selectionModel: https://github.com/kleopatra/swingempire-fx/wiki/SelectionModel
11-06-2020

hmm .. really think it's a _bug_ to not fully support list change notifications: without, there's no way around writing buggy client code. Sigh...
10-12-2014