Everybody knows that when you update the data in a Swing table, it's both easiest and laziest to call fireTableStructureChanged(). But what if you want to do it "right"? Then you compute which data was updated, added or removed, and fire the relevant events. However, the row sorter architecture builds an order mapping which depends on the size of the table, the upshot of which is that your first responsibility after changing the return value of getRowCount() is to fire the relevant insert or delete method. If you fire the update method first, the sort-cache gets broken, and life will never be the same again. I think this is an instance of fragile programming in the JDK, as code should be written to be definitionally, rather than procedurally correct, and the RowSorter isn't.