Thread safety issues can be very subtle, and uses may not be aware that listeners they are using are not thread-safe. I don't think we should throw our hands up and say "it's not our fault" that the user depended on the current implementation.

Here's my proposal:

In addListener(), check if the `RunListener` is annotated with `@ThreadSafe` (http://jcip.net/annotations/doc/net/jcip/annotations/ThreadSafe.html). If it is, add it directly.

If the listener is not annotated with `@ThreadSafe`, then we wrap the listener with a decorator that synchronizes every call to the `RunListener` delegate.  To be perfectly backwards-compatible, we should have all the listener decorators synchronize on the same object instance, so no two non-thread-safe listeners are called concurrently.

We could do this without having a runtime dependency between JUnit and the JSR 305 annotations (just a compile-time dependency when we build JUnit). As far as I can tell, we won't even need a runtime dependency on the annotations even if we annotate some of the build-in JUnit listeners with `@ThreadSafe`. Of course, if users use JUnit without the JSR 305 annotations on the classpath, we would not be able to tell if a listener is thread-safe and would have to assume it isn't.

Te other obvious option is to have our own annotation for this (`Concurrent`?) but if we use `ThreadSafe` it would be more consistent, and projects could annotate their classes today before the next version of JUnit is available.