Users Survey

What features of Glazed Lists are you using?

- In general, Glazed Lists is easy to use for the standard tasks (sorting, filtering in tables ...). You get productive very quickly.
- Compare GlazedLists with most other projects out there, and you see that somehow it has managed to consistently come up with an easy approach to most things.

- There's always a few bugs here and there, but every project has that. More unit testing would help.
- In the past I've also struggled with table selection problems - I'm not sure if these still exist (I came up with a workaround long ago, so I won't notice a fix internal to GlazedLists)?
- Release more often with smaller increments.
- forgetting to dispose TransformedLists can cause memory leaks.

- SWT and JFace is currenty being addressed. This is very important to me, and I'm trying to help here and there.
- I think SWT/JFace and Swing are different enough that they should be separate extensions.

- GlazedList codebase could be refactored to more strictly enforce separation among modules and make it more evident. It would have a core component that everyone would use for list transformations, event processing, etc. that is totally independent of the type of widget, chart, etc. being used. The developer would only use the separate extensions for Swing, SWT, JFreeChart, etc. that they need. Communication between the core and an extension would *only* occur through defined, public APIs--not through any internal stuff.

- (2) ListEvent should provide the deleted element, Some of my custom EventLists could benefit from this.
- provide 'element moved' event
- Paging support in Jtables for EventLists

- Out of the box Hibernate integration.
- bind an EventList to a JDBC RowSet, updating the database on edits

- Make locks reentrant? If my thread already holds a write lock on an EventList, I could obtain another read lock or write lock on the same list in the same thread. The locks would use a counter to know how many times my thread has locked a list so it knows if I have the lock and unlock calls balanced.
- Rather than having to write:

mylist.getReadWriteLock().writeLock().unlock()

all the time, I should be able to shorten it to just:

mylist.writeUnlock().

- Correct locking can be tricky (CollectionList/CompositeList!)
- Locking can be rather complex if you write your own transformations. We often have the case that the EventLists are buried within some complex model hierarchy. This model hierarchy gets replaced by a new instance. Hence, we cannot always easily enforce that all lists used in a composite share the same lock.
- From a developer view, it's not always clear to me, when a list implementation should aquire the required locks itself or should rely on the calling client code to hold the locks.

- I would like to see the BufferedView idea fleshed out so that you can try out changes to an EventList and then call commit to propagate those changes to the backing EventList as a single event. You should be able to have multiple views open on the same backing EventList. I would like to be able to begin, commit or rollback the changes kind of like you can with a database transaction. See: https://glazedlists.dev.java.net/servlets/ReadMsg?list=users&msgNo=1462
- I would like to see batching added to the event mechanism to increase performance. For example if I call addAll() to add 10,000 objects to a SortedList, it would do the insertion as one batch and then sort the indexes rather than do 10,000 separate ordered insertions.