The Java Event Handling Model

[Mickie Bottiglieri]

Forevent handling across multiple threads in a single JVM, I found some good candidates like Jetlang. But in my search for a distributed equivalent , I couldn't find anything that was lightweight enough to offer good performance.

Edit:Putting numbers to indicate performance is a bit difficult. But for example, if you implement a heartbeating mechanism using events and the heartbeat interval is 5 seconds, the heartbeat receiver should receive a sent heartbeat within say a second or two.

Generally, a lightweight implementation gives good performance. A event handling mechanism involving a web server or any kind of centralized hub requiring powerful hardware (definitely not lightweight) to give good performance is not what I'm looking for.

For distributed Event processing you could use Esper.It could process up to 500 000 event/s on a dual CPU 2GHz Intel based hardware.It's very stable because many banks use this solution. It supports JMS input and output adapter based on Spring JMS templates. So you could use any JMS implementation for event processing, i.e. ActiveMQ.

Whichever tool you use I'd recommend hiding the middleware APIs from your application logic. For example if you used the Apache Camel approach to hiding middleware you could then easily switch from AMQP to SEDA to JMS to ActiveMQ to JavaSpaces to your own custom MINA transport based on your exact requirements.

If you want to use a message broker I'd recommend using Apache ActiveMQ which is the most popular and powerful open source message broker with the largest most active community behind it both inside Apache and outside it.

You can make an architecture in which your triggers a publish a document in capped collection and your observer thread waits for it using a tailable cursor. If you did not understand what I have said above you need to brush up your MongoDB and java skills

Avis is also being used for chat, virtual presence, and smart room automation where typically 10-20 computers are communicating over an Avis-based messaging bus. Its commercial cousin (Mantara Elvin) is used for high-volume commercial trade event processing.

The Beeper class implements the ActionListener interface, which contains one method: actionPerformed. Since Beeper implements ActionListener, a Beeper object can register as a listener for the action events that buttons fire. Once the Beeper has been registered using the Button addActionListener method, the Beeper's actionPerformed method is called every time the button is clicked.

The event model, which you saw at its simplest in the preceding example, is quite powerful and flexible. Any number of event listener objects can listen for all kinds of events from any number of event source objects. For example, a program might create one listener per event source. Or a program might have a single listener for all events from all sources. A program can even have more than one listener for a single kind of event from a single event source.

Each event is represented by an object that gives information about the event and identifies the event source. Event sources are often components or models, but other kinds of objects can also be event sources.

Whenever you want to detect events from a particular component, first check the how-to section for that component. A list of the component how-to sections is here. The how-to sections give examples of handling the events that you are most likely to care about. In How to Use Color Choosers, for instance, you will find an example of writing a change listener to track when the color changes in the color chooser.

The following example demonstrates that event listeners can be registered on multiple objects and that the same event can be sent to multiple listeners. The example contains two event sources (JButton instances) and two event listeners. One of the event listeners (an instance of a class called MultiListener) listens for events from both buttons. When it receives an event, it adds the event's "action command" (which is set to the text on the button's label) to the top text area. The second event listener (an instance of a class called Eavesdropper) listens for events on only one of the buttons. When it receives an event, it adds the action command to the bottom text area.

In the above code, both MultiListener and Eavesdropper implement the ActionListener interface and register as action listeners using the JButton addActionListener method. Both classes' implementations of the actionPerformed method are similar: they simply add the event's action command to a text area.

As fas i have seen i can register listener classes to swing components to handle events. That is OK but i have to implement a class that implements e.g. the ActionListener interface to handle an event and then implement the actionPerformed method. That means ONE class FOR each event i have to handle?

Conclusion: ONE method to handle events fired from swing components..is it possible? Is the creation of ONE class for each the event the only way? Can't i route event handling to specific methods for a single class?

The other three will all allow you to do what you want (just add , WindowListener to the implements list for exaple). You likely want the inner class or outer class implementing the listener way to do what you want. I suggest that because the listener is likely very highly coupled to your program, and you will need to do a large set of "if" statements to figure out which control was acted on to perform the actual action (you use evt.getSource() to figure out which control was being acted on and then comare it to your instance variables to see which it was).

However, unless you are in memory constrained device, such as an Android phone, you probably should not do one method for all listeners as it can easily lead to very bad code. If memory is an issue, then go for it, but if it isn't you are better of doing one of the following things:

I prefer this way because it forces the methods out of the listeners, which means I only have one place to look for the code (not scattered throughout the inner classes). It also means that it is possible that aMethod() and bMethod() can be reused - if the code is in a listener that isn't practical (it is possible, but not worth the effort).

Doing it the above way is also consistent, and I prefer consistency over most things unless there is a good reason not do it. For instance on the Android I do not do that since class creation is expensive (I still have the listener call methods only, but the class itself implements the listeners and I do an if statement).

But this is not the recommended way to do it for various reasons. Why do you have an issue with creating a listener for every event to be received? It's the Java model for handling UI events, and if anyone else uses your code or you ever use someone else code it's going to be expected.

I must admit, I am a C/C++ guy. I am not a fan of Java, but have done a couple of apps in it when I needed cross-platform functionality. I have one more need for Java at the moment, and the event handlers are not firing.

The issue is that the swing devices that I have placed on my GUI, are not firing their event handlers. The debugger is working and I get breakpoints that function as expected elsewhere....Unless those breakpoints are set in event handlers. After a lot of digging, it has become apparent to me that the event handlers themselves for the swing widgets are simply not firing. I don't know if this is a JDK 8* issue or a NetBeans issue. If I get no replies by the weekend, I will remove the java 8 stuff, and go with the JDK 7 stuff. But that is a blind stab in the dark as far as I am concernedt.

I come from Code::Blocks, wxWidgets, using C/C++ background. I have done C/C++ for 35 years now. But in Java, which is not my strength, I have no idea where to start looking to determine why the event handlers aren't firing. I don't know if I need to start looking into the installed JDK's, or the NetBeans environment - and if so - where?

If this was a wxWidgets issue, I would look to determine if I had compiled the wxWidgets suite correctly. But with Java/NetBeans, all the swing widgets come down the wire with it so I do not know where to look.

I have followed the wiki in NetBeans to ensure that my project, and my environment were setup correctly and using/pointing to the correct JDK. Beyond that - I have no clue where to look next to determine the problem. I have also nuked the .netbeans folder and started over. No change with the issue.

Would it be possible to share your code, or at least the excerpts of how you try to use a handler? I don't mean to sound condescending, but this does sound more like an issue in your code than something that would be fixed by trying to shuffle your setup and libraries around (there haven't been any really relevant changes to Swing components between 1.7 and 1.8 anyway) one thing that might have a very slight chance of being an issue with your environment, would be that you run e.g. Gnome on Wayland as opposed to Xorg and there being a compatibility problem in Xwayland.

Well it turns out that unless you use Bindings, updating a UI from model values or listenting for user actions involes an eventing system that needs quite a lot of work when used like it is promoted by Swing (i.e. WindowListener):

In the main method we first create a new instance of the example class and add this instance as listener to the Enumeration/event type. It has static methods for adding and removing Listeners so this is straight forward.

Next the event SOME of the type SimpleEvent is raised. As the enumeration variable IS the event it has a raise method. So this is completly decoupled from any class actually raising the event. Here the raise method is public but you can still make it package protected for example if you like to limit which class is allowed to raise events. So the event SOME of the event type SimpleEvent is like the previously mentioned windowsActivated event of the event type WindowEvent.

3a8082e126