<Swing Dev> Review request for 6894632: Removing rows from a DefaultTableModel with a RowSorter deselectes last row

[Sergey Bylokhov]

Hi, Semyon.
There is a problem which we discussed offline already. This change fix 
the problem described in the bug report, but it contradicts the 
specification of this method, which state that tableChanged should 
clears the selection if any. So the specification should be updated also 
via ccc: in this CR if you have no plan to backport it to jdk8, or in 
separate CR if you plan to backport it to jdk8.

06.03.15 15:30, Semyon Sadetsky wrote:
> Hi Sergey,
>
> Good catch! Yes it should be inverted.
> I fix that and added more extensive test scenarios to double check 
> different table states.
> Please review.
> It's here:
> http://cr.openjdk.java.net/~alexsch/semyon-sadetsky/6894632/webrev.02/
>
> Thanks!
> Semyon
>
> On 3/6/2015 1:26 AM, Sergey Bylokhov wrote:
>> Hi, Semyon .
>> Are you sure that this new if-statement is correct? it seems that it 
>> should be opposite. No?
>>
>> On 04.03.2015 13:45, Alexander Scherbatiy wrote:
>>> The fix looks good to me.
>>>
>>>   Thanks,
>>>   Alexandr.
>>>
>>> On 3/4/2015 12:29 PM, Semyon Sadetsky wrote:
>>>> No, because it wouldn't be a valid state. The primary sort column 
>>>> is always the first. If primary is unsorted then there are no more 
>>>> sorted columns.
>>>>
>>>> On 3/4/2015 11:54 AM, Alexander Scherbatiy wrote:
>>>>>
>>>>>  Is it possible that getSortKeys() methods returns some sort keys 
>>>>> where the first has unsorted sort order but others do not.
>>>>>
>>>>>  Thanks,
>>>>>  Alexandr.
>>>>>
>>>>> On 3/2/2015 5:47 PM, Semyon Sadetsky wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Please review the fix: 
>>>>>> http://cr.openjdk.java.net/~alexsch/semyon-sadetsky/6894632/webrev.01/ 
>>>>>>
>>>>>> for bug: https://bugs.openjdk.java.net/browse/JDK-6894632
>>>>>>
>>>>>> The thing is the sorter logic uses its internal data structures 
>>>>>> to restore selection when the table model has been changed.
>>>>>> For performance reason this internal data is created only upon 
>>>>>> the table sort call. If sortable JTable is initialized with no 
>>>>>> sort order specified the table sort is not executed and table 
>>>>>> remains unsorted as JTable without sorting capability.
>>>>>> When the model of table in such state is changed the 
>>>>>> corresponding event handler logic still called the sorter to 
>>>>>> transform selection. But since the sorter internal cache was 
>>>>>> empty the transformation failed in cases when the selection index 
>>>>>> exceeds the new table rows count.
>>>>>> Now with the fix the sorter is updated with table model change 
>>>>>> event only if the table is really sorted.
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>


-- 
Best regards, Sergey.