Lead, Anchor and a new ListSelectionModel bug

Today I discovered a new bug in Glazed Lists' EventSelectionModel. That class implements ListSelectionModel, which a JTable uses to manage the current selection. One of these duties is to manage the lead and anchor indices, which are used for dragging a selection with the mouse. Where the mouse started the drag is the anchor, where it is currently is the lead. Everything between them shall become selected! Now this all broke down in a fairly simple case. If the user selects an anchor and then filters the list, the EventSelectionModel kept that same old anchor index - even if the list shrank so much that the anchor index was out of range. When the user would select a new lead (via shift-click), the incorrect anchor was called upon and an IndexOutOfBoundsException was thrown. This is all fixed now, but it was quite a nasty little bug, and it had been in the code for a long long time.

It makes me wonder:
  • Had anyone else ever seen this behaviour? It had never been reported.
  • How many more bugs are in the code?

    I'm fairly confident with our code, but it irks me to see that such an obvious bug had stayed hidden so long!
  • We've probably never come across this bug because out of the many places we use EventTableModel, there is only a small handful that we use an EventSelectionModel. The EventTableModel & EventLists are the real reason we're using Glazed Lists. The selection logic is icing on the cake, but we've only used it to solve a few problems.

    Edward Dale