Holger Brands

Holger has pointed out the prudent issue: ObservableElementList is not Swing-specific, so it cannot mandate that it delivers events on the EDT. It seems to me there are a few...

I only mentioned the SwingProxyEventList as a way to deliver list events on the EDT, not as a solution to Jeff's original problem, so we agree here. Regarding James' solution...

Great point Holger! ObservableElementList.elementChanged(..) does already acquires a write lock so you don't need to write your own Connector implementation. So, officially the recommended solution is as simple as acquiring...

Upon more thought, I believe I'm incorrect and you actually do have to write your own Connector which acquires the writeLock before calling elementChanged(). The issue is centered around guarding...

Guys, Thanks so much for the quick responses (that I haven't been able to keep up with). My thoughts on how this issue arises are as follows: Two threads in...

Minor amendment to my prior scenario: EDT: ObservableElementList.dispose() called A: Bean (element of above ObservableElementList) property changed and event fired via PropertyChangeSupport A: Property change propagates to JavaBeanEventListConnector's PropertyChangeHandler EDT:...

Jeff, your suggestion is quite reasonable given your requirements, however, it's not something we can add to the GL core (i.e. to our own Connector) for two reasons: 1) Except...

Theoretically, after this discussion I would now change ObservableElementList.elementChanged(..) to not lock the list internally, but let the caller of the method decide when to lock. So, our default BeanConnector...

Guys, Thanks for the responses. I understand the issues surrounding maintaining a consistent and usable API. Where does this leave me if I need to create a one-off implementation of...

We are moving back from yml format to property files, so that automatic conversion would be quite handy to have also in Eclipse STS. Unfortunately, I guess this will come...