u can think of making a class that

- extends java.util.Observable
- has a pvt Collection member (set/list/map)
- public getter setter and other public methods that you need (to
add , modify collection )

regards
lavnish

Well I have written some code that attaches any custom Observer
interface to any java.util.Observable. The code will generate adapter
classes *on the fly* that will downcast from Observable to the custom
observer interface:

public class SelectionObserverAdapter implements java.util.Observer
{
    private SelectionObserver so;

    public SelectionObserverAdapter(SelectionObserver s)
    {
        if ( s==null )
        {
            throw new NullPointerException("Selection observer is null.");
        }

        so = s;
    }

    public void update(Observable obs, Object arg)
    {
        so.update((Selection)obs);
    }

}

Any Observable will have some custom adapter attached to be notified
on update. I wanted to avoid the downcast for every Observer
implementation and use custom observers like

public interface SelectionObserver extends GenericObserver
{
    public void update(Selection s);
}

public interface EmailConstraintsObserver extends GenericObserver
{
    public void update(EmailConstraints ec);
}

...

The observing class then only has to implement the respective custom
interfaces. Note attaching the two is done via generating byte code,
if I would'nt do this, I'd not only have to create the concrete
Observer interface but also an adapter class, which is a maintenance
nightmare. Since it works so nicely without this listener stuff I was
looking for Observable compatible collections...

Side notes:

1. The adapter mainly acts as a "method multiplexer", it calls the
right method due to the downcast in the update method.
2. I know the object of interest in observer is Object arg, I wanted
to get around downcasting as much as possible.
3. The code will add n adapters for every n custom observers
implemented in the observing class, so Observable will do n updates.
As this is only intended for a few connections, the overhead of
calling notifyObserver n times is not (yet?) recognizable. This is
still much cleaner than using some if then else construct with
downcasts to determine the concrete object's class.
4. Of course, I used some naming conventions for the whole class
generation stuff...

Well..... this explanation has gotton much bigger than intended. I
hope that the basic idea has become clear. In any case this is getting
a little off-topic now - I just wanted to outline my motivation.

I'm not really a friend of Java's listener concept, can't explain why
really... ?-/

Karsten