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.