Holger Brands

Solution 2 is interesting for performance reasons. But using our underlying observable list will do the job for us with a small change (like solution 1). Thanks for the solutions....

A knwon workaround is to use another (older) ThreadProxyEventList implementation when using JideTable. I'll attach the source files for it and an updated example that should work. The implementation used...

Java source files demonstrating the workaround. by brands

I'm pretty sure you have assertions enabled? Please try to disable assertions for Glazed Lists and try again: http://www.glazedlists.com/documentation/faq#TOC-Performance Please let us know if that solves your issue. by brands

Yes, you are right. I had assertions enabled. I knew that assertions degrade performance, and I thought I had checked before I submitted this issue. But I did oversee a...

Because different code paths are taken: With a prefilled list CollectionList#listChanged is called which in turn calls CollectionList#handleInsert It produces insert events like 0 -> elem0 0 -> elem1 0...

Half of this defect has been completed. In particular, EventTableModel EventListModel EventComboBoxModel (by virtue of extending EventListModel) now all acquire the EventList's read lock during the constructor's execution. The relevant...

GH-331 has been marked as a duplicate of this issue. *** by jessewilson

Check out some useful comments in GH-331, a duplicate of this issue. by jessewilson

Jeff, to understand your problem correctly, let me rephrase: you call ObservableElementList.dispose() on the EDT concurrently, in a non-EDT thread you update a bean that's in the source list -->...