glazedlists / glazedlists Goto Github PK

The problem is in this code:

class ListTable
...

public void notifyListChanges(ListChangeEvent listChanges) {
// for avoiding extra selection events
ignoreSelectionEvents = true;
// when all events hae already been processed by clearing the event queue
if(!listChanges.hasNext())

{ return; // notify all changes simultaneously }

it is needed to add this line

ignoreSelectionEvents = false;

before that return. Without that line, it could happen that
ignoreSelectionEvents remains false and selection event are no more propagated.

[GLAZEDLISTS-9] created by ildella

UniqueList needs to provide access to non-mandatory change events for
overlaying lists which want to listen to them.

[GLAZEDLISTS-35] created by kevinmaltby

Hi,

at minimum the ListTable has no removeSelectionListener(SelectionListener)
method ...

Any plans to correct this?

Cheers,

Joern

[GLAZEDLISTS-16] created by jessewilson

SubList should be implemented. This should be an MutationList on its own, that starts with the initial
size and accepts add() and remove() from source list.

[GLAZEDLISTS-21] created by jessewilson

Glazed Lists needs a UniqueList that can take two lists and show only the unique values.

[GLAZEDLISTS-27] created by jessewilson

Sometimes I receive this exception that seems to be connected to a problem in
getSelected() methods in ListTable.

java.lang.IndexOutOfBoundsException: cannot get from tree of size 14 at 47
at
com.odellengineeringltd.glazedlists.util.IndexedTreeNode.getNodeWithIndex(IndexedTreeNode.java:81)
at
com.odellengineeringltd.glazedlists.util.IndexedTree.getNode(IndexedTree.java:55)
at com.odellengineeringltd.glazedlists.SortedList.get(SortedList.java:228)
at
com.odellengineeringltd.glazedlists.jtable.ListTable.getSelected(ListTable.java:227)
at
net.della.mcube.outliner.OutlinersBuilder$2.filterMatches(OutlinersBuilder.java:77)
at
net.della.mcube.util.CustomFilteredList.filterMatches(CustomFilteredList.java:38)
at
com.odellengineeringltd.glazedlists.AbstractFilterList.notifyListChanges(AbstractFilterList.java:93)
at
com.odellengineeringltd.glazedlists.event.ListChangeSequence.commitAtomicChange(ListChangeSequence.java:154)
at net.della.mcube.util.QueryList.refresh(QueryList.java:110)
at net.della.mcube.util.QueryList$RefreshTask.run(QueryList.java:127)
at java.util.TimerThread.mainLoop(Timer.java:432)
at java.util.TimerThread.run(Timer.java:382)

[GLAZEDLISTS-12] created by ildella

The height() method on the IndexedTreeNode is not optimized and prevents the
IndexedTreeNode from functioning efficiently. The method has O runtime while proper
optimization should yield O(log n) runtime.

This is because the height() method does not cache the height of the values at the nodes.

Fix the height as done for issue GH-21 with SparseListNode and the IndexedTree will perform
much more efficiently.

[GLAZEDLISTS-10] created by jessewilson

These changes make the code easier for new users at the expense of requiring existing users to change
their imports. Therefore the changes should be made very carefully. If possible a tool should be
referenced to automatically convert .java files for existing users.

First off, com.odellengineeringltd.glazedlists is a mouthful. This should be changed to O'Dell
Engineering's new standard package, ca.odell.glazedlists.

...glazedlists.listselectionmodel should be renamed to ...glazedlists.selection.

In ...glazedlists.jtable:
ListTable should be EventJTable
SelectionListener should be moved to ...glazedlists.selection
BasicSelectionListener should be moved to ...glazedlists.selection

Finally the following classes should be verified working or removed:
...glazedlists.jtextfield.ArrayStringCompleter
...glazedlists.jtextfield.CompletedField
...glazedlists.jtextfield.ComponentCaution
...glazedlists.jtextfield.ListStringCompleter
...glazedlists.jtextfield.StringCompleter
...glazedlists.jtextfield.ValidatedField
...glazedlists.jtable.StyledDocumentEditor
...glazedlists.jtable.WritableListTable
...glazedlists.jtable.WritableTableFormat
...glazedlists.query.QueryListManager

As I have already said, these changes will ruin Glazed Lists programs. Therefore all Glazed Lists users
should be notified before making any changes and copies of the Glazed Lists jar file and source should
be permanently archived for users with these packages.

[GLAZEDLISTS-20] created by jessewilson

UniqueList currently does not forward events on when a DELETE is encountered in
the following instance:

The element being removed is modelled in the unique view and has at least one
duplicate. This should result in the duplicate being modelled in the unique
view and an update event being forwarded.

In some circumstances, such as on a call to clear() on the source list,
forwarding this event causes the following exception:

Change blocks U.0 and D.0-1 intersect
java.lang.IllegalStateException: Change blocks U.0 and D.0-1 intersect
at com.odellengineeringltd.glazedlists.event.ListChangeBlock.requiresSwap
(ListChangeBlock.java:185)...

This fix will require altering the current strategy for dealing with change
collisions in ListChangeBlock.

[GLAZEDLISTS-34] created by kevinmaltby

I got the following exception:

[tasks] Interrupting worker thread to run Adding Article
apple.awt.EventQueueExceptionHandler Caught Throwable :
java.lang.ArrayIndexOutOfBoundsException: Cannot get selection index 0, list size 0
at
com.odellengineeringltd.glazedlists.listselectionmodel.SelectionModelEventList$EventListSelectionMode
l.isSelectedIndex(SelectionModelEventList.java:505)
at javax.swing.JTable.isRowSelected(JTable.java:1451)
at javax.swing.JTable.isCellSelected(JTable.java:1481)
at javax.swing.JTable.prepareRenderer(JTable.java:3725)
at javax.swing.plaf.basic.BasicTableUI.paintCell(BasicTableUI.java:1149)
at javax.swing.plaf.basic.BasicTableUI.paintCells(BasicTableUI.java:1051)
at javax.swing.plaf.basic.BasicTableUI.paint(BasicTableUI.java:974)
at javax.swing.plaf.ComponentUI.update(ComponentUI.java:142)
at javax.swing.JComponent.paintComponent(JComponent.java:541)
at javax.swing.JComponent.paint(JComponent.java:808)
at javax.swing.JComponent._paintImmediately(JComponent.java:4695)
at javax.swing.JComponent.paintImmediately(JComponent.java:4488)
at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:410)
at
javax.swing.SystemEventQueueUtilities$ComponentWorkRequest.run(SystemEventQueueUtilities.java:
117)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:178)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:454)
at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:234)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:184)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:178)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:170)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:100)
apple.awt.EventQueueExceptionHandler Caught Throwable :
java.lang.ArrayIndexOutOfBoundsException: Cannot get selection index 0, list size 0
at
com.odellengineeringltd.glazedlists.listselectionmodel.SelectionModelEventList$EventListSelectionMode
l.isSelectedIndex(SelectionModelEventList.java:505)
at javax.swing.JTable.isRowSelected(JTable.java:1451)
at javax.swing.JTable.isCellSelected(JTable.java:1481)
at javax.swing.JTable.prepareRenderer(JTable.java:3725)
at javax.swing.plaf.basic.BasicTableUI.paintCell(BasicTableUI.java:1149)
at javax.swing.plaf.basic.BasicTableUI.paintCells(BasicTableUI.java:1051)
at javax.swing.plaf.basic.BasicTableUI.paint(BasicTableUI.java:974)
at javax.swing.plaf.ComponentUI.update(ComponentUI.java:142)
at javax.swing.JComponent.paintComponent(JComponent.java:541)
at javax.swing.JComponent.paint(JComponent.java:808)
at javax.swing.JComponent.paintChildren(JComponent.java:647)
at javax.swing.JComponent.paint(JComponent.java:817)
at javax.swing.JViewport.paint(JViewport.java:774)
at javax.swing.JComponent.paintChildren(JComponent.java:647)
at javax.swing.JComponent.paint(JComponent.java:817)
at javax.swing.JComponent._paintImmediately(JComponent.java:4695)
at javax.swing.JComponent.paintImmediately(JComponent.java:4488)
at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:410)
at
javax.swing.SystemEventQueueUtilities$ComponentWorkRequest.run(SystemEventQueueUtilities.java:
117)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:178)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:454)
at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:234)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:184)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:178)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:170)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:100)

[GLAZEDLISTS-17] created by jessewilson

SortedList should support raw order when the current comparator is NULL.

[GLAZEDLISTS-33] created by jessewilson

SortedList fails upon an intensive amount of filtering. The SortedListTest must be updated to catch this
failure and the SortedList should also be fixed to remedy the problem.

[junit] FILTER: 4, 5, 1, 6, 2, 3, 2, 8, 1, 3,
[junit] SORTED: 1, 1, 2, 3, 2, 3, 4, 8, 5, 6,

[GLAZEDLISTS-40] created by jessewilson

This code doesn't seem to work properly:
(variable "songs" is a BasicEventList)

public int cleanFromMissingFiles() {
Iterator it = songs.iterator();
while (it.hasNext())

{ MP3Song song = (MP3Song) it.next(); File f = new File(song.getPath()); if (!f.exists()) it.remove(); }

}

if there are 2 items to remove, after removing the first, the iterator return
false at the next call to hasNext()
if, for example, there are 8 items to remove, the hasNext() return false after
the 4th remove() calls.
And so on...

the rest of the code is right, in fact, with this code:

public int cleanFromMissingFiles() {
List list = new LinkedList();
list.addAll(songs);
Iterator it = list.iterator();
while (it.hasNext())

{ MP3Song song = (MP3Song) it.next(); File f = new File(song.getPath()); if (!f.exists()) it.remove(); }

songs.clear();
songs.addAll(list);
}

everything is all right.

hope this can help.
bye.

[GLAZEDLISTS-3] created by ildella

When the sorting of a list changes, the TableComparatorChooser fails to respond to this change
appropriately. The TableComparatorChooser should show the proper icon, even if the sorted list's
comparator was selected elsewhere.

[GLAZEDLISTS-38] created by jessewilson

The CachingList will be of growing importance as Glazed Lists are used on the network.

The current implementation of CachingList dumps the entire cache whenever any changes to the list
occur. The CachingList should only dump values which have been invalidated.

[GLAZEDLISTS-22] created by jessewilson

Glazed Lists' new CompositeList combines multiple event lists into one.

This class is not thread-safe. In particular, it may be possible to cause a deadlock when one thread is
reading the CompositeList while another thread is writing a list that the CompositeList is composed of.

[GLAZEDLISTS-25] created by jessewilson

The Migrationkit's DynamicQueryList class is not forwarding events.

[GLAZEDLISTS-48] created by jessewilson

As Kevin and I were working on the CachingList problems today, we came up with some clever new
ideas for a powerful replacement for CachingList:

• background loading. Calls to get() return a default value immediately, then load the actual value in
  the background. Finally fire a updated() event when the actual value is loaded.

• bulk loading via an API. Create a Caching API for performing BulkLoading. This is not really a
  MutationList because it would require more than an EventList as a source. Bulk loading could be faster
  but it is definitely a big fat ugly pig to implement.

• footprint that is bounded by max cache size and NOT by the size of the source list. This will be
  necessary for arbitrarily large source lists on finitely powerful computers.

Regardless of where we go forward with Caching, it will be necessary to find some real-world cases that
require caching before we commit serious time to the problem. Such cases will enable us to have a
user's perspective on caching.

[GLAZEDLISTS-32] created by jessewilson

Glazed Lists version 0.8 is the last release before Glazed Lists undergoes the major API change.

Glazed Lists 0.8 will be a release that should be permanently available on the Glazed Lists webpage for
existing users, but such users should be encouraged to migrate to Glazed Lists 0.9.

Glazed Lists v0.8 does not inlcude:

• the renaming of APIs and classes
• the new concurrency model

It depents upon the following issues:
33 - SortedList raw order support
34 - UniqueList sometimes does not forward events on a DELETE
29 - ToString on BasicEventList, MutationList no good
30 - Verify ListTable changeSizeRepaintAllThreshhold works

[GLAZEDLISTS-37] created by jessewilson

The toString value on Java Lists is like "[lemon, orange, apple, banana]"
but on Glazed Lists it is like "com.odellengineeringltd.glazedlists.BasicEventList@f4d448ce"

[GLAZEDLISTS-29] created by jessewilson

The SparseListNode's height() method slow. More formally, this method is potentially O
and it should be optimized to be O(1).

This is insignificant in small lists but huge in large lists. In my brief profiling I discovered
that height() can consume 75% of the access time for large lists.

[GLAZEDLISTS-5] created by jessewilson

The ListChangeSequence grows as more and more atomic changes are created. For a long-
running Glazed Lists application the memory usage may become a serious performance
problem.

The ListChangeSequence should null out atomic changes when they are no longer in use
and shift the array list when it grows too large.

[GLAZEDLISTS-13] created by jessewilson

This issue depends upon all issues to be resolved for the 0.9 release.

These issues include the name refactoring and API stability.

Glazed Lists 0.9 is a release intended to have 100% compatibility with 1.0. This includes:

• class & package names
• concurrency strategy
• event sequence strategy

[GLAZEDLISTS-41] created by jessewilson

Glazed Lists does not support remove() on FilterLists. It simply throws an Exception.

Glazed Lists should support remove(). It should also support set().

To provide protection, there should be a MutationList called ReadOnlyList that throws an exception
upon a remove() or a set.

[GLAZEDLISTS-18] created by jessewilson

Currently the reader/writer locks lock ALL lists when any mutation list is being modified (ie. re-sorted).

The reader/writer locks should be changed to only lock dependent lists when such a modification takes
place.

This applies to:

• AbstractFilterList
• SortedList
• UniqueList
• CachingList
• and potentially others

[GLAZEDLISTS-42] created by jessewilson

The CachingList acquires a WriteLock when it may already have a ReadLock.

This is DANGEROUS! It is possible that two CachingLists may each have readlocks, and contest over a
write lock to their doom!

[GLAZEDLISTS-43] created by jessewilson

If you have a CaseInsensitiveFilterList with many entries and you filter for "foo", then the
list will be filtered three times! Because the list is "live" it filters once after the user types
"f", another time after they have typed "fo" and finally a third time after they have
completed "foo".

This is great when filtering is very fast and the list is short but it leads to unnecessary
performance lags when the list is large and filtering isn't as fast.

The CaseInsensitiveFilterList should have a non-"live" mode where the list is only filtered
after the user presses the Enter key in the search box. There could also be a "filter"
button to activate the filter after the filter text has been entered.

[GLAZEDLISTS-7] created by jessewilson

Lists that evaluate the values such as SortedList and FilteredList may break if the change event has
indicies that arrive out of order.

There should be a test for this added to the unit tests and a fix should be made if the problem is
legitimate.

[GLAZEDLISTS-28] created by jessewilson

Suppose we have a list of Objects, each of which has a date created.

It should be possible to create a filter that filters for where the date created is less than or greater than
a specified threshhold. This should be possible for any criteria that can take a range of values - in
effect anything that is Comparable.

Currently this is possible using the AbstractFilterList, but it is not 'smart' enough to know how
adjustments in the criteria require only a subset of the values to be readjusted. A clever implementation
of this would use a sorted set, and binary search to find the seperator between those that meet the
criteria and those that do not.

I was thinking a "Date Slider" Swing widget would be a good prototype of this!

[GLAZEDLISTS-47] created by jessewilson

As documented in the developer newsgroup, I want to build a model that allows list changes to be
distributed across the network.

https://glazedlists.dev.java.net/servlets/ReadMsg?list=dev&msgNo=11
https://glazedlists.dev.java.net/servlets/ReadMsg?list=dev&msgNo=12

I will create a descrete event simulation model in order to test out what network strategies are most
effective. Also I think that this package should be implemented exclusively using the buffered java.nio
package if possible.

[GLAZEDLISTS-19] created by jessewilson

The current filter code for CaseInsensitiveFilterList fails to work when the filter text
contains regular-expression characters such as dot.

Fix this to handle special characters as they should be.

[GLAZEDLISTS-2] created by jessewilson

WritableMutationLists allow modifications to be made to the list that may behave differently than
expected. The solution is to implement a DeltaList, which is a mutation list that provides as-expected
results when they would not otherwise be possible.

From issue 18:

Daniel Bonin and I were discussing modifyable views and we came up with some observations. When
using FilterList, SortedList or the like, you can have inconsistent behaviour. For example, the following
code wil fail.

list x = ...
x.add(0, "Jesse");
assert("Jesse".equals(x.get(0));

This can fail because the inserted value "Jesse" gets filtered out or sorted to a different location.

Our solution: a happy list. The happy list "fakes" success as the method directed. It basically keeps
track of local changes to make the changes appear consistent. This can be used with GUIs to allow the
user to verify their modifications without losing the filtering and sorting.

The happy list will be called "DeltaList" and it will keep track of both the source list and a set of deltas
that have been performed. When an insert at x occurs, the delta list simulates that the insert occured at
x, even if the insert was sorted or filtered to a different location.

[GLAZEDLISTS-24] created by jessewilson

I am delighted with the performance, flexibility and ease of use of your platform, which I am
currently evaluating for use in a table intensive application for my employer.

Our application needs to display tabular data which gets notified through JMS. That means,
ultimately, that data arrives via a callback method in out code. I am therefore using a
BasicEventList as base list, encapsulated in a SortedList and a subclass of AbstractFilterList as a
means of providing the functionality (sorting & filtering by various criteria) that we need.

The only problem so far arises with keeping selected rows between data insertions. I set the
underlying table selection model to ListSelectionModel.MULTIPLE_INTERVAL_SELECTION (anyway,
as it is the default value). A thread keeps adding rows to the table, at a rate of 10 per second (to
test performance). I have noticed that whenever I select a row, further row insertions may
modify the number of selected rows. In particular, if a new row has the same internal index as
the currently selected one, it is guaranteed I will end up with two selected rows.

That seems to be your intended behaviour as per the documentation of the class SelectionList;
however, I tried to modify it in order to suppress this behaviour to no avail. In particular, I
suppressed the lines marked inside SelectionList.notifyListChanges():
// when an element is inserted, it is selected if its index was selected
} else if(changeType == ListChangeBlock.INSERT) {
    // when selected, add the flag and fire a selection event
    if(previouslySelected)

{         flagList.add(index, Boolean.TRUE); // <--- SUPRESS         updates.appendChange(previousSelectionIndex, ListChangeBlock.INSERT); // <--- SUPRESS     // when not selected, just add the space     }

else

{         flagList.add(index, null);     }

I tried other changes, including the method SelectionList.valueChanged(). Do you have any
suggestion to solve this problem? Is it a bug in your code? In that case, I'd be willing to help and
contribute back to your project any bugfixes I develop. I can also provide you with my testing
code, but at this stage it's really simple: the thread inserting fake data rows does so in an
invokeLater() block, and uses a java.util.Timer for scheduling data feed.

The problem does not manifest when I set the table selection model to
ListSelectionModel.SINGLE_SELECTION, by the way.

Thank you for your time and for providing the Java Community with such a promising piece of
work.

Yours
Iván Rivera Rodríguez

[GLAZEDLISTS-15] created by jessewilson

The current implementation of filtering uses a N*N*M algorithm to re-filter when the list
changes, for M changes on a list of size N.

It is necessary to improve this runtime by using more appropriate data structures inside
the AbstractFilterList.

[GLAZEDLISTS-1] created by jessewilson

Maybe there is a problem in TableComparatorSelector.

I set tableHeader.setReorderingAllowed(true) on a table which has its own
TableComparatorSelector.
I move a column. After moving, the index of the column is changed, but the
modelIndex remains unchanged.
This is wel handled in method mouseClicked with trhis code

int viewColumn = columnModel.getColumnIndexAtX(e.getX());
int column = table.convertColumnIndexToModel(viewColumn);

the last method, which rewrite the table header of all the columns, has the
following code:

// and set the name of the table header to the current comparator
for(int c = 0; c < table.getColumnCount(); c++) {
if(c == column)

{ table.getColumnModel().getColumn(column).setHeaderValue(sortedHeader); }

else

{ String header = listTable.getTableFormat().getFieldName(c); table.getColumnModel().getColumn(c).setHeaderValue(header); }

}

this method doesn't seem to handle difference between column index and model index.
In my app, when I move a column and then click on the header for resorting the
table, all the header value happen to move from their position. And this seems
to be caused by that portion of code wich, I guess, has to use the view index
and not the model index of the column.

If I am right, that code has to handle difference between index and model index.
If I am wrong, there are different way to handle this thing?

[GLAZEDLISTS-4] created by ildella

Some users have had problems with the behaviour of Glazed Lists when the
changeSizeRepaintAllThreshhold is low.

Verify that the behaviour is:

• correct
• faster than using single changes

[GLAZEDLISTS-30] created by jessewilson

The UniqueList should be writable. Some write methods to include:

add(), remove(), set() . . .

The most interesting ones to implement will be the remove() methods as they may require removing
multiple duplicates from the source list.

[GLAZEDLISTS-45] created by jessewilson

MutationList getRootList was

public EventList getRootList()

{ return source; }

as of revision 1.3 on CVS.

In revision 1.4, it is:

/**

• For implementing the EventList interface. This returns the root of the
• source list, or this if this list has no source.
  */
  /*
  public EventList getRootList() { if(source == this) return this; return source.getRootList(); }

and this broke all my code and my coomprehension of Glazed Lists.

Is this correct?

[GLAZEDLISTS-6] created by ildella

Suppose we have a List "alphabet" containing "A", "B", "C", "D", "E", "F".
If we call alphabet.subList(1, 3).clear(), then the list alphabet should change to "A", "D", "E", "F".
But Glazed Lists clears the entire list alphabet.

Similar problems exist upon clearing filtered lists, etc.

This problem exists in the following List methods:
clear()
remove(Object)
removeAll(Collection)
retainAll(Collection)

[GLAZEDLISTS-44] created by jessewilson

Glazed Lists needs to support JList alongside JTable and JComboBox.

It should be very straightforward to change between JList and JTable in an application:

• The selection interfaces should be the same
• The renderers should be the same

From Fred at l2fprod.com:
> I was looking at an equivalent of "ListTable"
> but which would encapsulates a JList. Do you
> have this on your todo list? I guess it could
> share code with the ListTable

This functionality should get its own package,
com.odellengineeringltd.glazedlists.jlist
Perhaps the class name could be EventJList.

[GLAZEDLISTS-14] created by jessewilson

Glazed Lists' TableComparatorSelector does not:

• have chevrons or arrows to indicate sort order
• allow sorting by multiple columns simultaneously

These should be implemented by "beefing-up" TableComparatorSelector.

[GLAZEDLISTS-31] created by jessewilson

UniqueList.clear(), FilterList.clear(), SubList.clear() all can fire multiple ListEvents when only a single
operation is performed upon them.

This can be fixed by causing such lists to not propogate changes until they are all done.

[GLAZEDLISTS-46] created by jessewilson

Glazed Lists does not support SWT. This toolkit is growing in importance and Glazed Lists is well suited
for this platform.

Some things to consider:

• I need an SWT 'expert', either by becoming one or by finding a volunteer
• SWT compilation into the .jar file must be conditional. SWT support should be in source-form only
  and compiled only if SWT classes are available on the user's class path.
• From my initial research, SWT is not as model-driven as Swing. Although this does not pose a
  problem it may require a change in approach
• We need to choose an SWT version to support. 3.0 is coming out soon but I have no idea what the
  actual SWT users in the field are using.

[GLAZEDLISTS-50] created by jessewilson

This list type is based on the Bag ADT and is currently unnamed.

This class will sit on top of a UniqueList, and listen to all change events
from the UniqueList to correctly provide access to not only a view which is
guaranteed to be unique, but also the number of duplicate values for each
unique value.

An example usage would be a list of votes for favourite pop.

Source Unique View Unique, Counted
------------------------------------------------------
Pepsi| Coke | Coke x 3
Coke | MountainDew | Mountain Dew
Sprite | Pepsi | Pepsi x 2
Pepsi| Sprite | Sprite
Mountain Dew | |
Coke | |
Coke | |
------------------------------------------------------

Clearly this could provide a valuable list view.

[GLAZEDLISTS-36] created by kevinmaltby

The current Glazed Lists uses global locks for all reads and writes. It would higher performance to use a
reader/writer lock instead.

The reader/writer lock could be either requested via eventList.getLock().aquireRead() or via
eventList.aquireReadLock(). I think I prefer using getLock(), which returns an object implementing a
ReaderWriterLock interface. That way I can easily swap out the lock implementation.

[GLAZEDLISTS-26] created by jessewilson

This problem will be very difficult to solve using the current Glazed Lists framework, but it is a valid
problem. Sorting clears the selection.

The only fix I can think of is to add a new type of event alongside INSERT, UPDATE and DELETE which is
called MOVE. I think it is kind of an ugly hack on principal because it will impact all other lists if it is
implemented.

I will have to give this one some more thought. Saving selection by value may be one option but that is
also rather a big ugly hack.

[GLAZEDLISTS-39] created by jessewilson

Glazed Lists needs a new tutorial. It would be great if this tutorial involved a newer, more exciting and
more powerful demo app.

My current two ideas are:

• a bugzilla XML browser
• a Pop3 client

Such involve lots of lists and could take good advantage of Glazed Lists' ability to transform lists.

The demo should involve:

• Multiple-criterea sorting
• Text Filtering & Custom Filtering
• UniqueList, UniqueList on a derived list
• Transformed List
• JTable, JComboBox & JList

The demo should not rely on third-party libraries or tools for simplicity.

[GLAZEDLISTS-49] created by jessewilson

I like having the ability to alternate colors on each of the rows of my tables so
that they look more like a ledger. Since ListTable creates the JTable object it
makes it impossible to use this approach to render this.

I propose to expose this method into ListTable so that it can be overriden if
necessary.

[GLAZEDLISTS-11] created by philblais

As Glazed Lists gets bigger in scope it is becoming very urgent to create a set of unit tests.

There should be a package such as .glazedlists.test that is only compiled if the JUnit libraries are
detected on the classpath. If they are, then these test files can be built. They can then be tested with a
"test" target in the project buildfile.

Finally these test classes shall not be included in the library distribution.

[GLAZEDLISTS-23] created by jessewilson

There are two things that happen when a list changes:

• the ListChangeEvent is populated with the change information
• the notifyListChanges() method is called on all listeners

Sometimes as a consequence of multi-threading, multiple change events are processed in
a single notifyListChanges() methods. When the notifyListChanges() is called on a different
thread than where the changes were created, that method is required to verify that there
are changes left to be processed using:
listChanges.hasNext()

This is performed by the ListTable because it receives all events on the SwingThread via
ListChangeListenerEventThreadProxy:
public void notifyListChanges(ListChangeEvent listChanges) {
...
// when all events hae already been processed by clearing the event queue
if(!listChanges.hasNext()) {
return;
...

Unfortunately the listChanges.hasNext() method is broken, and throws an
IndexOutOfBoundsException when there are no more changes:
java.lang.IndexOutOfBoundsException: Index: 43, Size: 43
at java.util.ArrayList.RangeCheck(ArrayList.java:507)
at java.util.ArrayList.get(ArrayList.java:324)
at
com.odellengineeringltd.glazedlists.event.ListChangeSequence.getBlockCount(ListChangeSe
quence.java:181)
at
com.odellengineeringltd.glazedlists.event.ListChangeEvent.hasNext(ListChangeEvent.java:
124)
at com.odellengineeringltd.glazedlists.jtable.ListTable.notifyListChanges(ListTable.java:
158)
at
com.odellengineeringltd.glazedlists.event.ListChangeListenerEventThreadProxy.run(ListCha
ngeListenerEventThreadProxy.java:54)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:178)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:454)
at
java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:201)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:
151)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:145)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:137)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:100)

[GLAZEDLISTS-8] created by jessewilson