Question

The JXTable from the SwingX project has a method to set a RowFilter directly on the JXTable (see JXTable#setRowFilter).

It is unclear to me what you need to do when the filter implementation is dynamic.

To compare: in the JDK they introduced the RowSorter interface in JDK1.6, and this interface allows to attach a RowSorterListener. If you have a dynamic RowSorter (which can also be used for filtering), you can fire an event to those listeners when the filter changes (although this requires that the filter has access to the RowSorter as there is no such thing as a DynamicRowFilter or RowFilterEvent in the JDK).

What I would expect is that I can set an “observable” RowFilter on the JXTable and that I have to do nothing. But as that seems not to be possible with the current API, what is the next best thing ?

• set the filter again each time it changes. Will this even have effect as it is the exact same instance as was previously set on the JXTable ?
• abuse the table events and just fire an event that your table model has been changed, which will retrigger the sorting/filtering
• do not use the setRowFilter method and create your own TableRowSorter and fall back on the JDK API.

Answer 1

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.