I am using TableSorter class to sort tables. There is a piece of optimization code that never gets called: getModelToView(). For that method to be called a check is performed (modelToView != null). But modelToView is assigned inside that method! This causes a single cell update to trigger fireTableDataChanged(). Is that a known bug? Is there a fix?
I am using the same version.
modelToView is assigned inside getModelToView().
Below is the only place in the class where getModelToView() is called.
However getModelToView() is never called because modelToView == null
if (e.getFirstRow() == e.getLastRow()
&& column != TableModelEvent.ALL_COLUMNS
&& getSortingStatus(column) == NOT_SORTED
&& modelToView != null) {
int viewIndex = getModelToView()[e.getFirstRow()];
fireTableChanged(new TableModelEvent(TableSorter.this,
viewIndex, viewIndex,
column, e.getType()));
return;
}
I see what you mean.. you're right, it seems like modelToView will always be null.
I found another bug.. when mouse is clicked on the tableheader area where it doesn't have any column (when table is stretched it can have no column there) , columnModel.getColumnIndexAtX(e.getX()) returns -1, and if the check there is not added, then get a runtime out-of-bounds exception on the following line columnModel.getColumn(viewColumn).getModelIndex() because viewColumn is set to -1. See the code snippet below:
public void mouseClicked(MouseEvent e) {
JTableHeader h = (JTableHeader) e.getSource();
TableColumnModel columnModel = h.getColumnModel();
int viewColumn = columnModel.getColumnIndexAtX(e.getX());
if(viewColumn == -1) { // added!
return;
}
int column = columnModel.getColumn(viewColumn).getModelIndex();
There's this comment about modelToView != null clause, but i'm not really sure what it means.. which opens the possibility that i could be wrong.. but even if I don't understand, I don't see how, since getModelToView method is private, and it's not getting called in TableSorter.
// The last check, for (modelToView != null) is to see if modelToView
// is already allocated. If we don't do this check; sorting can become
// a performance bottleneck for applications where cells
// change rapidly in different parts of the table. If cells
// change alternately in the sorting column and then outside of
// it this class can end up re-sorting on alternate cell updates -
// which can be a performance problem for large tables. The last
// clause avoids this problem.
