The use-case we have is a filter (not a rowfilter) which can be changed to filter out elements of a model, and we have a RowFilter based on that dynamic filter to filter out those elements
Repeating my comment: the RowFilter must be immutable. That was a concious design decision back when sorting/filtering was introduced into core. So the approach to implement "dynamic" filtering is to
- make your custom filter (not a rowFilter) observable
- implement a listener to that filter which creates a new RowFilter on changes
- set the rowFilter to the xtable (in SwingX) or to the DefaultRowSorter (in core)
Edit
I don't agree with that design, but couldn't sway him
should be: I didn't agree - meanwhile, I'm not so sure as I had been ;-)
The advantage of this approach is that the RowFilter is really small coin to implement and highly re-usable - just a simple predicate, nothing else. That allows simple logic compounding (and/or) of filters. No burden to notify on part of the filter, no burden on part of the sorter (or compound filter) to listen and update itself. Then taking into account that the "dynamics" of the filter change often comes from user interaction and something has to listen to those user triggers anyway, it's not a big deal to create a new rowFilter vs. updating an existing rowFilter.