In the case of permutation, I would not try to use add() and remove() for processing. This will make the indexes move and will confuse things (at least for me).
Conceptually, what you get is a range of affected elements and an array containing some numbers indicating where each element was moved. I think you understand so much. In your code you have
newIndex = getPermutation(oldIndex);
which means that the item was in oldIndex , you need to move it to newIndex . The wrinkle is that if you just do the movement directly, you can rewrite the element that has not yet been moved. I think the easiest way to handle this is to make a copy of the affected sub-range, and then just go through the permutation array and move the elements from the copy to their new positions. Code for this:
int from = c.getFrom(); int to = c.getTo(); List<DEST> copy = new ArrayList<>(dest.subList(from, to)); for (int oldIndex = from; oldIndex < to; oldIndex++) { int newIndex = c.getPermutation(oldIndex); dest.set(newIndex, copy.get(oldIndex - from)); }
This is a permutation, so each element ends somewhere, and not one is added or removed. This means that you donβt need to copy the range of the list, and you can move the elements one by one behind the chain of moves, using only one element of the temporary space. There may be several loop cycles, so you will also have to detect and process them. That sounds pretty complicated. I will leave this for the other respondent. :-) For my money, copying the affected range is simple and easy to understand.
Swapping and updated change modes are not triggered by normal list actions. If you look at javafx.collections.ObservableListBase , you will see a protocol that the list implementation can use to create information about a specific change. If the implementation provides the correct information to the nextPermutation or nextUpdate , this will cause these other other change modes. I am not sure what might call them in JavaFX. For example, the Node.toFront() and Node.toBack() methods for changing the stacking order of a node can potentially generate permutation changes, but they do not look. I donβt know anything about what might cause the update to change.
Semantically, I think that changing the update implies that the elements in this range of the list have changed, but the length of the list will remain the same. This contradicts the βreplacedβ change mode, where the range of elements can be replaced with a different number of elements. It may also be that changing the update means that the elements themselves have not been replaced - that is, the contents of the list have not changed - the internal state of the elements has simply changed.