What's the difference between Event Listeners & Handlers in Java?

In general terms of java, there are listeners & handlers for events.
I mean I use them unknowingly, just whichever is available in the API.

My question is, in what case do we use listeners and in what case do we use handlers for events?

What's the difference between them? Characteristics??

I've searched for reasons and I couldn't find a proper explanation for Java.

There's no formally defined difference between listeners and handlers. Some people would probably argue that they are interchangeable. To me however, they have slightly different meaning.

A listener is an object that subscribes for events from a source. Cf. the observer pattern. Usually you can have many listeners subscribing for each type of event, and they are added through addXyzListener methods.

Example: The MouseListener in the Java API.

A handler is an object that is responsible for handling certain events. A typical scenario would be to provide a handler for a specific event/task as an argument to a constructor, or set the handler through a setXyzHandler method. In other words, you usually have one handler for each type of event.

Example: The MemoryHandler in the Java API.

The most basic difference is the association

• Listener is associated with Event Source (Ex: key board)
• Handler is associated with an Event (Ex: keydown)

Generally speaking, there will only one central Handler Manager which manages all the events, while in case of Listener each Entity which wants to listen, will have to manage their own Collection of listeners

This is the way I see it:

A listener watches for an event to be fired. For example, a KeyListener waits for KeyEvents, a MessageListener waits for messages to arrive on a queue and so on.

The handler is responsible for dealing with the event. Normally, listeners and handlers go hand-in-hand. For example, the KeyListener tells the ExitHandler that "the letter Q was pressed" and the handler performs logic such as cleaning up resources and exiting the application gracefully. Similary a ButtonClickListener would tell the same ExitHandler that the "Exit button was clicked". So, in this case you have two different events, two different listeners but a single handler.

A listener is an object that is notified when an event occurs, and it has 2 major requirements- 1-it must have been registered with one or more sources to receive notifications about specific types of event 2-it must implements methods to receive and process these notifications. Handler is responsible for dealing with events.

A listener, listens for events which are data value objects which describe an event. When the event occurred and the order of events is often important. Pressing key '0' followed by '1' is different to '1' and '0'.

A handler, handles a complex object e.g. a new Socket connection. The handler might process the object for any length of time. The time of object creation and order is not so important. A connection from client0 or client1 can happen in any order.

I think the difference is subtle because a concrete Listener is an event-handler too or at least has a method that can be considered an event-handler. That is, a concrete Listener handles or manages the reaction to the event after receiving an event object(from the event-source) with all the usefull informations about the event just occurred(on the event-source). As this Listener has to implement an xxxListener interface that forces him to implement at least one method that is in turn executed by the event-source object when the event occurs, so the Listener itself can be considered an handler and more precisely, the method of the Listener interface implemented by the Listener object can be considered the real event-handler. So i view the event-handler as just the code that is executed in reaction to an event. This is different from a Listener object that is an element of a more abstract concept such as an Observer design pattern. This is my personal view of the subject.

To my mind, the most important difference is fact that we use listeners per event's source, in contrary to handler, which is per event type.

They're conceptually the same thing - an object that performs some action in response to a UI event. Generally, in Swing, these objects are called "handlers" at the look-and-feel level (for handling low-level widget events), and "listeners" at the more abstract UI level (where you'll be implementing your application logic).

EventHandler is introduced in the JavaFX for all the UI controls. Whereas the Listener is borrowed for Observables, such as properties.

The EventHandler is a way to distinguish observable events and the ui events.

I've been trying to make sense of all the info and I'm lost. I've looked at Delphi (Pascal), C, C++, java... nothing is clear.So, after a month, this is the problem as I see it. I may be totally off track, so please tell me... politely, please.

One event sender, one catcher as long as Sender registers the catcher. I have 4 dialog boxes that need to be updated each time a file (whose handling code is in another module than the 4 dialog boxes) changes. I considered updating each the old-fashioned way, but then I looked at Delphi events and message handling. Let's see:

File F (The Sender) is finished reading and should notify Dialogs 1..4 of the fact that there is now data for them to display and the user to play with. What is best?

Try to register Dialogs 1..4 as listeners and have the Sender trigger an OnUpdatedDataEvent somehow?

Try sending a message across the system, hoping that Dialogs 1..4 will catch it?

Notice that the event keeps things coupled while messaging do not...and are a pain to debug.

And I do wonder how the File block of code will be able to register 4 listeners (the dialog boxes)?

What I am looking at is the possibility of cascade calling, meaning caller calls one listener, whom calls the next... until it reaches the end of the chain. I even wonder if that is even possible.

An example:

Say File F is a list of languages. Now, DialogBox 1 does something to the list (adds a new language for instance); that combo box updates the F file; this in turn triggers a DataUpdatedEvent. the 4 Dialog boxes contain, say, TComboBoxes that display the language list when they pop up. I want the 4 boxes to notice the change and update their own combo box contents with the freshly updated File... without having to worry about how the combo boxes know they need to refresh their contents. If it works as envisioned the Sender parameter will carry across and the dialog box that triggered the dataUpdateEvent will be bypassed since it will already be updated. After all an if sender=self then continue to next event handler should be easy to implement.

All that because I want to exercise my brain... to prevent Alzheimer's, not very successfully I might add.

Suppose you just landed at the airport by plane at a new destination. you have someone waiting for you at the gate OR someone who will drive the taxi and take you to your hotel

The person waiting is the listener (waiting for an event like you are arriving) The person taking you to the hotel is the event handler (the action after you've arrived)

In JS, the listener waits for an event (e.g click) the handler does something father the "click" happened

It is semantics.

• Listener is interface.
• Adaptor is class that implements specific interface and provides empty implementation for its methods. This helps if you do not have to implement all methods of interface.
• Handler implements several interfaces or delegates calls to several interfaces.