Understanding EventBus for In‑Process Event Dispatch in Java

Traditionally, Java in‑process event dispatch relies on explicit registration between publishers and subscribers. EventBus was created to replace this explicit registration, offering better decoupling between components while not being a generic publish‑subscribe system for inter‑process communication.

Example

The following snippet shows a typical EventBus usage:

// Class is typically registered by the container.
class EventBusChangeRecorder {
    @Subscribe
    public void recordCustomerChange(ChangeEvent e) {
        recordChange(e.getChange());
    }
}

// somewhere during initialization
eventBus.register(new EventBusChangeRecorder());

// much later
public void changeCustomer() {
    ChangeEvent event = getChangeEvent();
    eventBus.post(event);
}

One‑Minute Guide

Migrating an existing in‑process event system to EventBus is straightforward.

Listeners

To listen for a specific event (e.g., CustomerChangeEvent ), define a method with a single parameter of that event type and annotate it with @Subscribe . Register the listener with eventBus.register(Object) , ensuring both producer and listener share the same EventBus instance.

EventBus also supports listening to super‑type events (e.g., EventObject or Object ) and automatically dispatches events to matching listeners, allowing wildcard generic types such as ? super XXX .

To detect events without listeners, subscribe to DeadEvent ; EventBus wraps unhandled events in a DeadEvent for easier debugging.

Producers

EventBus internally manages listener registration, eliminating the need for manual list handling or synchronization.

To publish an event, simply call eventBus.post(Object) . For asynchronous delivery, use the AsyncEventBus subclass.

Glossary

Event

An object that can be posted to the event bus.

Subscribe

Register a listener with the event bus.

Listener

An object providing a handler method to receive events.

Handler Method

A public method annotated with

@Subscribe

that processes events.

Publish

Sending an event to all matching listeners via the event bus.

FAQ

Why create an EventBus instance instead of using a singleton? Different components or contexts may need separate buses for isolation and easier testing. A global singleton is still possible if desired.

Can listeners be unregistered? Yes, via eventBus.unregister(Object) , though it is rarely needed because listeners typically live for the application’s lifetime.

Why use annotations instead of listener interfaces? Annotations allow handler methods to reside anywhere, provide clear intent, and avoid the limitations of single‑method interfaces.

What about generic handler interfaces? Java’s type erasure prevents a class from implementing the same generic interface with different type arguments, making a generic Handler<T> less practical for EventBus.

Does EventBus break static typing? No; the bus accepts any object, but each handler method must declare a concrete parameter type, enabling IDE navigation and refactoring.

What happens if a listener has no handler methods? Nothing; registration succeeds silently.

What compile‑time checks exist? The Java compiler ensures handler methods have a single parameter of a concrete type. Registering a malformed listener throws IllegalArgumentException at runtime.

How are undelivered events detected? If no handler matches an event, EventBus may log a warning. Registering a DeadEvent listener lets you capture and handle such cases.

How to test listeners? Since handlers are ordinary methods, test code can invoke them directly or simulate EventBus posting.

Why no generic magic on EventBus? Supporting all generic use‑cases would complicate the design and hinder extensibility; the current API focuses on the most common scenarios.

[Source: Concurrency Programming Network]