Re: RFR: 8196065: ListChangeListener getRemoved() returns items that were not removed. [v9]

2021-06-25 Thread Michael Strauß
On Fri, 25 Jun 2021 12:53:13 GMT, Kevin Rushforth wrote: >> Michael Strauß has updated the pull request incrementally with one >> additional commit since the last revision: >> >> changes as per review comments > >

Re: RFR: 8196065: ListChangeListener getRemoved() returns items that were not removed. [v9]

2021-06-25 Thread Kevin Rushforth
On Fri, 11 Jun 2021 20:26:24 GMT, Michael Strauß wrote: >> The documentation for `ObservableListBase.nextRemove` states that a single >> change always refers to the current state of the list, which likely means >> that multiple disjoint removed ranges need to be applied in order, otherwise >>

Re: RFR: 8196065: ListChangeListener getRemoved() returns items that were not removed. [v9]

2021-06-14 Thread Ambarish Rapte
On Fri, 11 Jun 2021 20:26:24 GMT, Michael Strauß wrote: >> The documentation for `ObservableListBase.nextRemove` states that a single >> change always refers to the current state of the list, which likely means >> that multiple disjoint removed ranges need to be applied in order, otherwise >>

Re: RFR: 8196065: ListChangeListener getRemoved() returns items that were not removed. [v9]

2021-06-11 Thread Michael Strauß
On Fri, 11 Jun 2021 20:26:24 GMT, Michael Strauß wrote: >> The documentation for `ObservableListBase.nextRemove` states that a single >> change always refers to the current state of the list, which likely means >> that multiple disjoint removed ranges need to be applied in order, otherwise >>

Re: RFR: 8196065: ListChangeListener getRemoved() returns items that were not removed. [v9]

2021-06-11 Thread Michael Strauß
> The documentation for `ObservableListBase.nextRemove` states that a single > change always refers to the current state of the list, which likely means > that multiple disjoint removed ranges need to be applied in order, otherwise > the next change's `getFrom` doesn't refer to the correct