<Swing Dev> [9] Review request for 8032874: ArrayIndexOutOfBoundsException in JTable while clearing data in JTable

[dmitry markov]

On 14/04/2014 17:06, Alexander Scherbatiy wrote:
> On 4/14/2014 4:33 PM, dmitry markov wrote:
>> Alexandr,
>>
>> Please find my answer below.
>>
>> Thanks,
>> Dmitry
>> On 14/04/2014 14:12, Alexander Scherbatiy wrote:
>>> On 4/14/2014 10:59 AM, dmitry markov wrote:
>>>> Hi Alexandr,
>>>>
>>>> Thank you for the review. According to the specification in 
>>>> ListSelectionModel: getAnchorSelectionIndex() and 
>>>> getLeadSelectionIndex() return the first index and the second index 
>>>> arguments from the most recent call to setSelectionInterval(), 
>>>> addSelectionInterval() or removeSelectionInterval(). So if -1 is 
>>>> not set explicitly via the methods described above, it is correct 
>>>> to return value which is not -1 even for empty selection. I guess, 
>>>> such behavior is intended for storing the information about the 
>>>> previous selection.
>>>      Is it possible that the lead selection index can be greater 
>>> than the table row numbers?
>> Yes, it is possible. The lead selection index may be greater or equal 
>> to the row count, (e.g. for case described in the bug the lead index 
>> is 0 for the empty selection).
>
>        What about if there are only 2 row counts in the table but the  
> lead selection index is 5? Will the 
> convertRowIndexToView(viewLeadIndex) method
>        works correctly in this case.
It will work properly in this case, since the lead index will be updated 
by DefaultListSelectionModel.removeIndexInterval(). The problem takes 
place only when we remove the last row from a table. In this case 
removeIndexInterval() does not update the lead and the anchor indexes, 
(i.e. they stay equal to 0). This causes failure in 
convertRowIndexToView() method, since we try to use it on empty 
selection. Possible way to avoid the problem is not invoke 
convertRowIndexToView() for empty selection.

I do not think we should change the current implementation of 
removeIndexInterval(), since it keeps the values of lead and anchor 
indexes in valid and correct range and prevents us from returning 
something strange, (e.g. -5, -10) as lead or anchor index of the 
previous selection.

Thanks,
Dmitry
>
>   Thanks,
>   Alexandr.
>
>>>
>>>      I seems that the getAdjustedIndex(index, row) method checks 
>>> both these cases.
>> That is right. The fix does the same thing as getAdjustedIndex() 
>> method. Unfortunately we can not use the method in the fix, since if 
>> I get it right getAdjustedIndex() is designed for work with 
>> selectionModel, but here we work with modelSelection.
>>>
>>>      Thanks,
>>>      Alexandr.
>>>>
>>>>
>>>> Thanks,
>>>> Dmitry
>>>> On 11/04/2014 17:07, Alexander Scherbatiy wrote:
>>>>> On 4/11/2014 4:36 PM, dmitry markov wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Could you review the fix for jdk9, please?
>>>>>>
>>>>>>     bug: https://bugs.openjdk.java.net/browse/JDK-8032874
>>>>>>     webrev: 
>>>>>> http://cr.openjdk.java.net/~dmarkov/8032874/jdk9/webrev.00/
>>>>>>
>>>>>> Problem description: If JTable has Sorter and Filter and selected 
>>>>>> row is removed ArrayIndexOutOfBoundsException will be thrown.
>>>>>> Fix: The method restoreSelection() in SortManager class should 
>>>>>> invoke convertRowIndexToView() only when modelSelection is NOT 
>>>>>> empty.
>>>>>
>>>>>     Is it the right behavior that 
>>>>> modelSelection.getLeadSelectionIndex() does not return -1 when 
>>>>> modelSelection.isSelectionEmpty() is true?
>>>>>
>>>>>    Thanks,
>>>>>    Alexandr.
>>>>>>
>>>>>> Thanks,
>>>>>> Dmitry
>>>>>
>>>>
>>>
>>
>