It sounds like you might not have looked at the source code for these two collection classes. Please take a look at the iterator in each class.

The null checks in CLQ aren't there to check for the case where someone inserts a null; they make sure the iterator is weakly consistent in the face of concurrent modification (and, possibly even to handle items removed before iteration starts; it's hard to tell).  Non-blocking algorithms are not free; in the case of CLQ the iterator has to do some reasonably complicated things to insure correctness, and that may not necessarily be fast. Worse, some non-blocking algorithms can have very poor performance in the face of concurrent modifications.

On the other hand, COWAL's iterator is always as fast as the `ArrayList` iterator (with the negligible addition of a single volatile read) no matter how many threads are trying to concurrently add or remove elements.

Yes, COWAL can block on insert. But I would argue that in 99.9% of the projects out there, all listeners are added before any tests are started. In fact, the only classes that can add listeners after the tests have started are runners.. Since the listeners are started before tests have started, there's only one thread and nothing will block. When a lock is uncontested, the JVM can pass through it very quickly.

One problem with COWAL is it has to make an array copy on every insert, so if n listeners are inserted it has to allocate n arrays and the whole thing is O(n^2).

Let's talk specifics: how many listeners does Surefire add, and when does it add them? If the answers are "less than four" and "before the tests are started", I guarantee that COWAL will be faster. It was designed to handle *exactly* this case.