I have to agree with Daniel. Perhaps a decent approach on catching exceptions during the send() might be:

protected final void send(Event event) {
final GenericListener[] tmp = listeners;

for (int i = tmp.length - 1; i >= 0; --i) {
try {
tmp[i].receive(this, event);
} catch (RuntimeException e) {
Thread.UncaughtExceptionHandler ueh =
Thread.getDefaultUncaughtExceptionHandler();

if (ueh != null)
ueh.uncaughtException(Thread.currentThread(), e);
log.log(Level.SEVERE, e.getMessage(), e);
}
}
}

Hi Warren,

Looking at it again, the behavior of your implementation matches the AWT's understanding of what it means to add or remove a Listener that overrides equals(). AWT classes use == comparison instead of the equals() method in this case. I had incorrectly assumed that the semantics of add(..) and remove(..) for listeners would be the same as for collections, in which equals(..) has to be used for correct comparison.

So your implementation has the same interpretation of Listener equality as the JDK and I retract my objection.

BTW, I'm not sure if I was clear, but my main point about exceptions is that a runtime exception in a listener should not kill the event delivery thread.

Thanks,
Daniel

Additional response to Daniel B.

It was late and I was hasty writing my last response, and so apologize for the poor writing. I managed to skip your point 3 completely, so:

3. I am confused about your statement. The Generators only use the == operator on Listeners. This is because redefining equals() for some class that happened to implement Listener is probably more of coincidence than something the designer had planned to take advantage of. Am I missing something here?

Response to Daniel B.

Thanks for liking the article!

1. Since addListener and removeListener is very rarely called) efficiency isn't really an issue here. Still, there is no reason to waste time, and so the version written are efficient. arraycopy would be equivalent (but arguably slower as you pointed out) in one case, but it is only appropriate for one of the loops (in addListener). The removeListner case is more subtle because it has to skip an element during the copy.

2. I agree about the exception propagation. I see no way to handle this from a general framework, so the specific listeners need to handle this. Thanks for this point.

Response to Roberto L.

ArrayList is great in general, but bad (less efficeint) in this case. Since we are trying to solve the problem for everyone we need to just have the efficient solution in this case. Think about the System.arraycopy mentioned by Daniel B.: you don't care that it is a nasty system specific implementation instead of a pretty for loop, but instead that it is correct, efficient, and easy to use. (Which incidentally is less efficient than the for loop for this very special case). The goal here is to provide a system tool analogous to arraycopy, but for Generators, so correctness, efficiency and usability. Not convinced? Look over the swing implementation for event generators --- it's pretty ugly stuff (and I think a version of the swing classes based on the proposed framework would be faster).

So far as the generics, I have to agree that type erasure is a huge pain in the neck. If you automatically generate code using the meta classes, they generate javadocs which point out the pitfalls and how to work around them. As far as solving the problem without type erasure, you can use the pre 1.5 meta tools in a 1.5 setting.

...And figure out who to write to to *erase* type erasure from the JDK! (My version would be to make the "erased" type and a cheap interface type for each of the specific types brought to life through a generic instantiation. This is a much better trade off between code size and usability compared to C++'s template mechanism). This discussion belongs elsewhere --- I can only work in the context of the framework provided :oP

I have a few comments on your otherwise excellent article:

1. System.arraycopy is often more clear than a copying loop. Of course, it would be slower than the loop with the presumably small array sizes you're dealing with.

2. Correct handling of exceptions is a crucial factor in a correct event generator. Listeners often contain code that is beyond the control of the author of the listening class. The code in the listeners can throw a RuntimeException. In your examples, this exception would be passed up to the caller of the event generator and other listeners would not receive the event. This is probably not the desired behavior.

3. In the unlikely event that your generator were to encounter a listener which overrode equals(), it would not work as expected.

I would suggest

i) Catching all exceptions in listeners and logging stack traces. In the absence of a log, they can go to the console. After an exception is caught, event delivery should continue.

ii) in the add and remove methods, convert the array to an ArrayList, perform the add/remove, then convert the ArrayList back to an array. It's not efficient, but it doesn't have to be and you gain correctness and clarity.

You are, of course, spot on in observing that an array is the best way to get both thread safety and minimum heap usage.

OK, so I like your pattern for the generator a lot, although I think I'd rather use an ArrayList instead of the Array... array handling can be much more error prone. But that really is a minor consideration.

The bigger problem, is in the generics. And it's not a gripe with your article but with erasure in general. The last time I coded something like this I had issues because the hierarchy I chose was such that a class could not implement two Listeners where the only difference was the parametrized type. I'm not sure I can think of an easy answer though.

Thanks again for the article.