commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Neil O'Toole <>
Subject Re: [collections] Notifying/Observable design choices
Date Wed, 11 Jun 2003 08:12:54 GMT

> - Event implementation class chosen by factory.
> - Event data is theoretically flexible, but limited in practice. In
> particular, the post-event cannot contain a copy of the state of the
> collection, or the size before the change occurred (ie. you can't
> replicate
> proposal #1)
> - Unsuited to certain collections (eg. LazyList)
> - Should give reasonable performance.
> - Relies on accurate result boolean.

There are muliple insightful issue raised here, and I believe I have
resolved them in the latest build. In particular the second problem
("limited in practice") has been eliminated. I don't have time to
document all the changes in this email right now, (but will in 3 or 4
days) but much of the javadoc has been updated. You can view it online

The source is at:

And a prebuilt binary:

Again, the package description is the place to start. The new build
includes significant new functionality (see 'EventAttribute') and an
attempt at the list/heuer design as a subpackage, and another
bare-bones event-package implementation in the 'simple' package. The
test suite has also been improved (though there's more to do). I did
not complete the implementation of the list/heuer design as I ran into
several issues/bugs with the design. Again I don't have time to go into
these in detail just now, but one that springs to mind is in the event

    public CollectionChangeEvent(CollectionEventSource source,
                                 int oldSize,
                                 int newSize,
                                 int changeIndex,
                                 int changeCount,
                                 Object changedElement,
                                 Collection changedElements,
                                 boolean bulkOperation)

Initially one might think that the 'changeIndex' datum is sufficient to
determine the indices of the items in the 'changedElements' collection,
but this is not necessarily the case. It works fine if you do, say:

 coll.addAll( 2, coll2);
as the added items have sequential indices. However, say you have a

 { b, a, b, a, c }
and you do:

 coll.removeAll( {a, c} );
This removes all the a's and c's, i.e. items with indices 1, 3 and 4.
However, the value of changeIndex would presumably be 0, and the
indices of the other items cannot be determined (as they are not

Also, it appears that modifications to a sublist do not result in
events being fired. I haven't investigated if this is an issue with the
AbstractListDecorator, but it is certainly the case that sublists of a
decorated list should retain the decoration of the super-list. A simple
example of the dangers if decoration is not implemented on the sublist
is if you could do something like this (thankfully you can't!):

Collections.unmodifiableList( list ).subList( 0, list.size()).clear();

There are some other elements of the implementation that I believe
could be enhanced, and I'll revisit these at the weekend, along with
several other interesting points that Stephen raised. I hope as well to
have put together something of a 'cookbook' by then, though the javadoc
is improved in the latest build.

- Neil

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message