What's the best collection to use for event-handlers?

Discussion in 'Java' started by Inertia_sublimation, Oct 10, 2004.

  1. Hello everyone. Im attempting to make a very simple multithreaded application.
    The problem Im having is deciding what kind of collection I need to use to hold
    classes that have methods triggered asynchronously. Eg: Class A implements
    FooListener, foo.addFooListener(anInstanceOfA) stores anInstanceOfA in one of
    foo's fields. I need to figure out what type of collection is best for that.

    I just recently downloaded Tiger, and took a look at what changed in the
    Collections API. I was extatic about the new for-loop functionality and
    generics, but noticed something even more interesting, as it seemed to pertain
    to extactly what I wanted to do: CopyOnWriteArraySet.

    CopyOnWriteArraySet's JavaDoc says its ideal to use for my purposes. Before
    encountering this, I was strongly considering taking the advice of the author of
    Hardcore Java, who recommends a WeakHashSet.

    What should I do? Should I use one over another? Should I subclass
    CopyOnWriteArraySet and make a WeakCopyOnWriteArraySet? What are the benefets of
    each decision?

    Thanks in advance!
     
    Inertia_sublimation, Oct 10, 2004
    #1
    1. Advertisements

  2. Inertia_sublimation

    Guest Guest

    I suggest separate List (probably an ArrayList) for each type of
    Listener. By using a List, there is a determined order in which each of
    the Listeners will get called. Your methods to add Listeners should check
    to see if your List already contains that instance.

    HTH,
    La'ie Techie
     
    Guest, Oct 11, 2004
    #2
    1. Advertisements

  3. This advice sounded a bit suspicious to me, but since I don't own a copy
    and haven't read the book Hardcore Java, I searched on Google and
    located this reference where the author advices using a WeakHashMap (not
    WeakHashSet) - I assume you're referring to the same.

    http://www.onjava.com/pub/a/onjava/2004/04/28/hardcorejava.html?page=2

    I have some reservations about this advice. For instance it appears to
    be slightly brittle in its design since the event firing code can throw
    a ConcurrentModificationException during event dispatching in case a GC
    cycle happens to remove one of the registered listeners in between.
    Also, this requires that any listeners registered *must* have a strong
    reference somewhere else in the program to ensure that it stays alive.
    So an anonymous listener registered with the common construct
    "addXXXListener(new XXXListener(){...};" is impossible to do because
    this listener object may be garbage collected at any time.

    While I concur with the author that there is a lot of sloppy code out
    there that causes memory leaks because of the misconception "Java
    developer does not have to worry about the memory of his program", I
    don't think there is a single shortcut solution to it and the one
    proposed by the author is certainly not the cureall solution that it is
    made out to be.

    Also I was a little bit curious about the author's terminology "the
    creation of circular reference trees that pin objects in memory and
    interfere with garbage collection" (that he is supposed to describe in
    chapter 11 of the book) because as far as my understanding goes,
    circular references are hardly a problem for most Java Garbage
    collectors. (But not having read the chapter, I would give him the
    benefit of doubt - may be he isn't really referring to circular
    references at all ?)
    You might also want to look at the implementation of the
    AWTEventMulticaster class. If you're looking for JDK 1.4 compatibility
    also, a custom class written on those lines would probably be a better
    bet since it provides thread safety and even allows addition / removal
    of listeners even while an event dispatching is in progress. (If the
    event you're trying to handle is an AWTEvent, you can use that class
    directly). I wouldn't really bother about putting in all the
    WeakReference code to alleviate a memory leak problem that may or may
    not exist. If you have any listeners that are transient in nature, just
    make sure they unregister themselves before being thrown away.

    BK
     
    Babu Kalakrishnan, Oct 13, 2004
    #3
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.