On Mon, 7 Oct 2024 16:25:22 GMT, Loay Ghreeb <d...@openjdk.org> wrote:
>> Fix an issue in `SortedList` where the sorting became incorrect when adding >> new items that are equal to existing items according to the comparator. The >> `SortedList` should consider the insertion index of these items to maintain >> the correct order. > > Loay Ghreeb has updated the pull request with a new target base due to a > merge or a rebase. The incremental webrev excludes the unrelated changes > brought in by the merge/rebase. The pull request contains seven additional > commits since the last revision: > > - Merge branch 'master' into SortedList > - Merge branch 'master' into SortedList > - Merge branch 'master' into SortedList > - Merge branch 'master' into SortedList > - Merge branch 'master' into SortedList > - Add test case > - Fix SortedList to maintain insertion order for equal elements Your example is only applicable to `TableView`. I don't see how you can add and remove sort orders to a single `SortedList`. What you can do is modify its `Comparator`, but there is no guarantee that reverting that change will get you back to the previous order regarding equal elements. Even if the sorted list provided a stable sort, this would not be guaranteed. Given a `SortedList` with a case-insensitive comparator of `["a", "b", "B", "C", "c"]` If I then change the comparator to case-sensitive (using ASCII table values), it becomes `["B", "C", "a", "b", "c"]` then if I restore the previous comparator and take into account stable sorting, it becomes `["a", "B", "b", "C", "c"]` which is different than the initial sorting. So, stable sort doesn't solve "undo". If you're trying to solve this at the list-level, you'll need an implementation of `SortedList` with memory - an "undo sorted list". This means that the problem is probably not in `SortedList`. As I wrote above, `TableView` says it offers a special case of this behavior: when reverting back to no sorting. `SortedList` says that with a `null` comparator it defaults back to the wrapped list order. Perhaps when all columns are unselected for sorting, a `null` comparator is imposed on the list. However, there is no guarantee that switching between sortings preserves any memory, as in your example. It's also not clear why it should. To summarize, the "memory" of the list exists in one place only, which is the backing list, and the sorted list gives a sorted "view" of it. There is no memory between sorts, as requested in your example. It looks like you will want to implement your own `TableView` sorting behavior. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1519#issuecomment-2417828896