RFR: JDK-6998249: Wrong behavior/Javadoc of JTable.tableChanged(TableModelEvent e)

Phil Race prr at openjdk.java.net
Fri Jan 28 22:22:09 UTC 2022


On Fri, 28 Jan 2022 20:03:10 GMT, Harshitha Onkar <duke at openjdk.java.net> wrote:

>> I said most of the doc is changing which is clearly not most of the doc for JTable so it means just this method.
>> 
>> To the latter point the doc you are proposing is asserting that it does not apply to rows.
>> Now since we also know this is all supposed to be code called ny the implementation and responded to by the implementation and even so we are NOT going to change anything because some code somewhere would break, nontheless we want to be sure the new code is what actually happens and not just what someone wrote in a  bug report several years ago. So go find the code that calls "new TableModelEvent" and point in this PR to how it guarantees the rows are in view order.
>
> @prrace After going through the code, I see that the `new TableModelEvent()` is called in setModel of JTable but I wasn't able to locate the code that does model-to-view coordinate mapping for rows from here. Within the `tableChanged` method I see `sortedTableChanged` method being called if ` sortManager != null ` which in turn calls `convertRowIndexToView` method (which is called when either sorter or model changes and sorting is enabled). I think this is the method that is responsible for mapping coordinate system from model to view for the rows.

I was just looking at this same code too - and that's how it looks to me.
So the claim in the report AND the evaluation both look wrong to me.
But verify this with testing. I am not sure but it seems like merely doing whatever it is to install
a RowSorter will ttigger that code path and the code the submitter pointed to is only used if
the model row == the view row ..

-------------

PR: https://git.openjdk.java.net/jdk/pull/7253



More information about the client-libs-dev mailing list