Some things to think about when defining events or writing listeners for them:
- Like any other class or interface in Java, it is possible to create package-protected event interfaces. This allows you to use Events in your design, without making them freely available to all API clients.
- It is more efficient to implement a listener class as a singleton (either using the @Singleton Guice annotation on the class, or binding the class in singleton scope in the Guice module). Singletons need to be implemented in a thread-safe way, but even if you don't use singletons you should still assume that your listener should be thread-safe, since the safety requirements are imposed by the class which raises events. In short, unless an Event interface is documented as not requiring thread-safe listeners, you should assume thread-safety is required.
- It will rarely be appropriate for your listener methods to modify arguments passed to them. Remember that the same arguments are passed to all listeners, and that furthermore you have no control over the order in which different registered listeners will be called. Changing the contents of a listener method parameter (for instance, calling mutator methods on it) can have negative consequences and cause unexpected results or violate validation requirements. Unless an Event interface documents what can validly be changed, assume nothing can.