Does not support table models that run listeners in the order they are registered instead of reverse order.

[tlf30]

Exception when adding row on JTable:

java.lang.IndexOutOfBoundsException: Index 21 out of bounds for length 21
    at jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
    at jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
    at jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
    at java.util.Objects.checkIndex(Objects.java:385)
    at java.util.ArrayList.get(ArrayList.java:427)
    at net.coderazzi.filters.gui.AdaptiveChoicesHandler$AdaptiveChoicesSupport.include(AdaptiveChoicesHandler.java:493)
    at javax.swing.DefaultRowSorter.include(DefaultRowSorter.java:942)
    at javax.swing.DefaultRowSorter.rowsInserted0(DefaultRowSorter.java:1054)
    at javax.swing.DefaultRowSorter.rowsInserted(DefaultRowSorter.java:879)
    at org.jdesktop.swingx.sort.DefaultSortController.rowsInserted(DefaultSortController.java:404)
    at javax.swing.JTable.notifySorter(JTable.java:4338)
    at javax.swing.JTable.sortedTableChanged(JTable.java:4186)
    at javax.swing.JTable.tableChanged(JTable.java:4463)
    at org.jdesktop.swingx.JXTable.tableChanged(JXTable.java:1561)
    at org.jdesktop.swingbinding.JTableBinding$BindingTableModel.fireTableModelEvent(JTableBinding.java:832)
    at org.jdesktop.swingbinding.JTableBinding$BindingTableModel.added(JTableBinding.java:791)
    at org.jdesktop.swingbinding.impl.ListBindingManager.listElementsAdded(ListBindingManager.java:123)
    at io.tlf.ow.fob.manager.ui.beans.SwingDeepObservableList.lambda$add$1(SwingDeepObservableList.java:76)
    at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:318)
    at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:773)
    at java.awt.EventQueue$4.run(EventQueue.java:720)
    at java.awt.EventQueue$4.run(EventQueue.java:714)
    at java.security.AccessController.doPrivileged(AccessController.java:400)
    at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:87)
    at java.awt.EventQueue.dispatchEvent(EventQueue.java:742)
    at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)
    at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
    at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
    at java.awt.EventDispatchThread.run(EventDispatchThread.java:90)

This is because some table models run the registered listeners in the order they were registered instead of the reverse order, so net.coderazzi.filters.gui.AdaptiveChoicesHandler$AdaptiveChoicesSupport.rowsAdded(AdaptiveChoicesHandler.java:257) is called second, not first.

This is from the javax.swing.table.AbstractTableModel

    public void fireTableRowsInserted(int firstRow, int lastRow) {
        fireTableChanged(new TableModelEvent(this, firstRow, lastRow,
                             TableModelEvent.ALL_COLUMNS, TableModelEvent.INSERT));
    }

This is from org.jdesktop.swingbinding.BindingTableModel

 private void fireTableModelEvent(TableModelEvent e) {
            for(TableModelListener listener : this.listeners) {
                listener.tableChanged(e);
            }

        }

[coderazzi]

Hi, Trevor, could you confirm that there are no multiple threads in place? Normally I have seen this error when adding rows outside the swing thread. Best regards, Luis

…

On Mar 6, 2025, at 2:34 AM, Trevor Flynn ***@***.***> wrote: Exception when adding row on JTable: java.lang.IndexOutOfBoundsException: Index 21 out of bounds for length 21 at jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100) at jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106) at jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302) at java.util.Objects.checkIndex(Objects.java:385) at java.util.ArrayList.get(ArrayList.java:427) at net.coderazzi.filters.gui.AdaptiveChoicesHandler$AdaptiveChoicesSupport.include(AdaptiveChoicesHandler.java:493) at javax.swing.DefaultRowSorter.include(DefaultRowSorter.java:942) at javax.swing.DefaultRowSorter.rowsInserted0(DefaultRowSorter.java:1054) at javax.swing.DefaultRowSorter.rowsInserted(DefaultRowSorter.java:879) at org.jdesktop.swingx.sort.DefaultSortController.rowsInserted(DefaultSortController.java:404) at javax.swing.JTable.notifySorter(JTable.java:4338) at javax.swing.JTable.sortedTableChanged(JTable.java:4186) at javax.swing.JTable.tableChanged(JTable.java:4463) at org.jdesktop.swingx.JXTable.tableChanged(JXTable.java:1561) at org.jdesktop.swingbinding.JTableBinding$BindingTableModel.fireTableModelEvent(JTableBinding.java:832) at org.jdesktop.swingbinding.JTableBinding$BindingTableModel.added(JTableBinding.java:791) at org.jdesktop.swingbinding.impl.ListBindingManager.listElementsAdded(ListBindingManager.java:123) at io.tlf.ow.fob.manager.ui.beans.SwingDeepObservableList.lambda$add$1(SwingDeepObservableList.java:76) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:318) at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:773) at java.awt.EventQueue$4.run(EventQueue.java:720) at java.awt.EventQueue$4.run(EventQueue.java:714) at java.security.AccessController.doPrivileged(AccessController.java:400) at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:87) at java.awt.EventQueue.dispatchEvent(EventQueue.java:742) at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) at java.awt.EventDispatchThread.run(EventDispatchThread.java:90) This is because some table models run the registered listeners in the order they were registered instead of the reverse order, so net.coderazzi.filters.gui.AdaptiveChoicesHandler$AdaptiveChoicesSupport.rowsAdded(AdaptiveChoicesHandler.java:257) is called second, not first. This is from the javax.swing.table.AbstractTableModel public void fireTableRowsInserted(int firstRow, int lastRow) { fireTableChanged(new TableModelEvent(this, firstRow, lastRow, TableModelEvent.ALL_COLUMNS, TableModelEvent.INSERT)); } This is from org.jdesktop.swingbinding.BindingTableModel private void fireTableModelEvent(TableModelEvent e) { for(TableModelListener listener : this.listeners) { listener.tableChanged(e); } } —

[tlf30]

Hello Luis, thank you for the quick reply. I honestly was not expecting to hear from you.

I created a small test case here: https://github.com/tlf30/tablefilter-swing/tree/issue-53

In order to get my IDE happy, I moved the examples into the source tree. The test file is here:
https://github.com/tlf30/tablefilter-swing/blob/issue-53/src/main/java/net/coderazzi/filters/examples/Test.java

I also added some debugging stack dumps in the code to see what order and what was calling the listeners. On my project, I forked beansbindings and reversed the order the listeners were call in, and that fixed the issue. I don't think it is an EDT violation issue, but I've said that before on other problems only to find some crazy way it was.

Although I ran into a different issue which I believe is also another beansbindings problem, but I found a mitigation for it so I've not looked into it. I'll build a test case for that problem later. It happens when an item is removed from the list and another item is readded back to back. Looks like an issue with the adaptive sorting. But that is a different discussion for a different issue.

[coderazzi]

Hi, Trevor, I downloaded your test and tried it out. I agree with you that this is not an EDT issue; SwingDeepObservableList is already taking care of calls outside the main swing thread. I have never used SwingDeepObservableList before, but I have reviewed its documentation. As I see it, it is way to represent a list that is observed for changes to update the user interface. With TableFilter, it follows the TableModel, so it expects that you update the table model, fire the change notification, and react to it. The Bindings class creates a specific table model (JTableBinding.BindingTableModel) for the table, where the backing collection is precisely the SwingDeepObservableList. Nice, simple. In your code, you add a new element to the observable list, which fires a tablechanged event, as expected. There are two listeners: one is the table, the other is the AdaptiveChoicesHandler class in the FilterHeader. The order should not matter. Yet you are receiving an error, which seems to indicate that the event is sent before the table model is updated. In the test class you sent me, I never run into exceptions, does the Test class represent properly the code where you are running into issues?? I would follow your add logic. In JtableBinding.BindingTableModel, the protected method added is the one that is firing the event after a model update. I would check if the mode has been properly updated by the time the AdaptiveChoicesHandler receives the change event (as that seems to be the issue). Cheers, Lu.

…

On Thu, Mar 6, 2025 at 8:10 PM Trevor Flynn ***@***.***> wrote: Hello Luis, thank you for the quick reply. I honestly was not expecting to hear from you. I created a small test case here: https://github.com/tlf30/tablefilter-swing/tree/issue-53 In order to get my IDE happy, I moved the examples into the source tree. The test file is here: https://github.com/tlf30/tablefilter-swing/blob/issue-53/src/main/java/net/coderazzi/filters/examples/Test.java I also added some debugging stack dumps in the code to see what order and what was calling the listeners. On my project, I forked beansbindings and reversed the order the listeners were call in, and that fixed the issue. I don't think it is an EDT violation issue, but I've said that before on other problems only to find some crazy way it was. Although I ran into a different issue which I believe is also another beansbindings problem, but I found a mitigation for it so I've not looked into it. I'll build a test case for that problem later. It happens when an item is removed from the list and another item is readded back to back. Looks like an issue with the adaptive sorting. But that is a different discussion for a different issue. — Reply to this email directly, view it on GitHub <#53 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAH54IJGTNXE57GOTYHCYLT2TCMRHAVCNFSM6AAAAABYNPDONOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOMBUG4YTSNBXGM> . You are receiving this because you commented.Message ID: ***@***.***> [image: tlf30]*tlf30* left a comment (coderazzi/tablefilter-swing#53) <#53 (comment)> Hello Luis, thank you for the quick reply. I honestly was not expecting to hear from you. I created a small test case here: https://github.com/tlf30/tablefilter-swing/tree/issue-53 In order to get my IDE happy, I moved the examples into the source tree. The test file is here: https://github.com/tlf30/tablefilter-swing/blob/issue-53/src/main/java/net/coderazzi/filters/examples/Test.java I also added some debugging stack dumps in the code to see what order and what was calling the listeners. On my project, I forked beansbindings and reversed the order the listeners were call in, and that fixed the issue. I don't think it is an EDT violation issue, but I've said that before on other problems only to find some crazy way it was. Although I ran into a different issue which I believe is also another beansbindings problem, but I found a mitigation for it so I've not looked into it. I'll build a test case for that problem later. It happens when an item is removed from the list and another item is readded back to back. Looks like an issue with the adaptive sorting. But that is a different discussion for a different issue. — Reply to this email directly, view it on GitHub <#53 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAH54IJGTNXE57GOTYHCYLT2TCMRHAVCNFSM6AAAAABYNPDONOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOMBUG4YTSNBXGM> . You are receiving this because you commented.Message ID: ***@***.***>

[tlf30]

Ah, I apologize. I had put a check in the include function on the AdaptiveChoicesHandler to see what it would do.

My change

Back to original

If you uncomment the if statement (restoring the code back to the original) then you will see the error.

[coderazzi]

Hi, Trevor, it looks like your idea of changing the listeners order was spot-on; looking at the AbstractTableModel class, the implementation for a table change event is: Object[] listeners = listenerList.getListenerList(); // Process the listeners last to first, notifying // those that are interested in this event for (int i = listeners.length-2; i>=0; i-=2) { if (listeners[i]==TableModelListener.class) { ((TableModelListener)listeners[i+1]).tableChanged(e); } } So it is iterating the list in reverse order (the minus 2 is because the listeners are inserted, first its interface, then its instance). What is happening is that if the Table receives first the change event, and there is a sorter in place (the filter header itself), it launches the sorting logic BEFORE the sorter itself knows that the model has changed. But it asks the sorter for each row in the model, including the rows not yet added. The tablefilter works internally by disabling the filters when it detects a model change; then recreates them. There are two solutions here: 1- Change the order of listeners in the binding class. This aligns it with the standard way the AbstractTableModel works. 2- Modify the AdapatativeChoiceHandler in the way you did it: something like: @OverRide public boolean include(RowFilter.Entry entry) { Integer row = (Integer) entry.getIdentifier(); if (row < rows.size()) { RowInfo ri = rows.get((Integer) entry.getIdentifier()); if (ri != null) { return ri.is(); } } return true; } But in this case, the filter is not automatically re-applied. That is, if there is a filter and a new row does not match the filter, it will still be shown (and if we return false instead), the opposite would happen. When the TableFilterHeader receives the notification that the model has changed, it does not apply the filtering itself: it lets the table handle it. I do not see how this can be done properly to handle both ways of sorting the listeners. Could you report this as a Bindings issue? Best, Lu

…

On Sat, Mar 8, 2025 at 4:46 AM Trevor Flynn ***@***.***> wrote: Ah, I apologize. I had put a check in the include function on the AdaptiveChoicesHandler to see what it would do. image.png (view on web) <https://github.com/user-attachments/assets/ef2b75c8-0254-4273-8f76-bb8011bd4767> If you uncomment the if statement (restoring the code back to the original) then you will see the error. — Reply to this email directly, view it on GitHub <#53 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAH54IM4P3NEQESPGLMTVB32TJRYNAVCNFSM6AAAAABYNPDONOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOMBXHE4DKOJSGM> . You are receiving this because you commented.Message ID: ***@***.***> [image: tlf30]*tlf30* left a comment (coderazzi/tablefilter-swing#53) <#53 (comment)> Ah, I apologize. I had put a check in the include function on the AdaptiveChoicesHandler to see what it would do. image.png (view on web) <https://github.com/user-attachments/assets/ef2b75c8-0254-4273-8f76-bb8011bd4767> If you uncomment the if statement (restoring the code back to the original) then you will see the error. — Reply to this email directly, view it on GitHub <#53 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAH54IM4P3NEQESPGLMTVB32TJRYNAVCNFSM6AAAAABYNPDONOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOMBXHE4DKOJSGM> . You are receiving this because you commented.Message ID: ***@***.***>

[tlf30]

Thank you Luis,
Unfortunately, beansbinding is no longer maintained, it was originally a JSR (almost two decades ago). A lot of UI builders still use it since there is no good replacement (NetBeans and JFroumDesigner). I have made the corrections to the order the listeners get call in my fork.

I was thinking about how to tackle the issue to make the listeners not order dependent. Perhaps something like detecting the out of order listener calls, and using an invokeLater to retrigger the first listener. Just thinking for anyone else who runs into this.

[coderazzi]

Hi, I believe there is a simple solution: Change xTable1 = new JXTable(model); into: xTable1 = new JXTable(model){ @OverRide public void tableChanged(TableModelEvent e) { SwingUtilities.invokeLater(()->{super.tableChanged(e);}); }}; This way, the logic in the table is processed AFTER the logic change in the filterheader. Not the cleanest solution, but effective! The test class works fine, without the modifications you had done on the AdaptativeChoicesHandler. Could you try it on your side? Best, Lu.

…

On Sat, Mar 8, 2025 at 6:45 PM Trevor Flynn ***@***.***> wrote: Thank you Luis, Unfortunately, beansbinding is no longer maintained, it was originally a JSR (almost two decades ago). A lot of UI builders still use it since there is no good replacement (NetBeans and JFroumDesigner). I have made the corrections to the order the listeners get call in my fork. I was thinking about how to tackle the issue to make the listeners not order dependent. Perhaps something like detecting the out of order listener calls, and using an invokeLater to retrigger the first listener. Just thinking for anyone else who runs into this. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***> tlf30 left a comment (coderazzi/tablefilter-swing#53) Thank you Luis, Unfortunately, beansbinding is no longer maintained, it was originally a JSR (almost two decades ago). A lot of UI builders still use it since there is no good replacement (NetBeans and JFroumDesigner). I have made the corrections to the order the listeners get call in my fork. I was thinking about how to tackle the issue to make the listeners not order dependent. Perhaps something like detecting the out of order listener calls, and using an invokeLater to retrigger the first listener. Just thinking for anyone else who runs into this. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[tlf30]

I'll give that a try. I think that will fix a different issue I am having too.

[coderazzi]

Hi, Trevor, Did everything work finally? Best, Lu.

…

On Mar 8, 2025, at 7:12 PM, Trevor Flynn ***@***.***> wrote: tlf30 left a comment (coderazzi/tablefilter-swing#53) I'll give that a try. I think that will fix a different issue I am having too. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented. <#53 (comment)> <https://github.com/notifications/unsubscribe-auth/AAH54IMZOSZRB7RKPQU3GQL2TM6JDAVCNFSM6AAAAABYNPDONOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOMBYGQ2TEMJWHE> tlf30 left a comment (coderazzi/tablefilter-swing#53) <#53 (comment)> I'll give that a try. I think that will fix a different issue I am having too. — Reply to this email directly, view it on GitHub <#53 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAH54IMZOSZRB7RKPQU3GQL2TM6JDAVCNFSM6AAAAABYNPDONOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOMBYGQ2TEMJWHE>. You are receiving this because you commented.