Shevek (shevek) wrote,

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.

It took me a month and a half to find that bug.
  • Post a new comment


    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.