Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
This article throws light on the problems inherent in traditional event-handling implementations using AWT/JFC and demonstrates six ways to get around them.
Note: This article assumes that the reader has a thorough understanding of the AWT event model. Experience with the Reflection API is necessary to modify or extend the five utility classes provided in this article.
Before getting into the guts of the system, let's take a quick peek at the event model mechanism in AWT and JFC.
The event source (typically a UI component) emits events through a predefined listener interface. Any object interested in
those events will register an implementation of the listener with the event source through an addXXXListener() method. Except for DocumentEvent, the rest of the events derive from the java.util.EventObject class. This is the essence of the event model; anything else is implementation detail. To get some background on the AWT/JFC
event model, see the Resources section at the end of the article.
There are some outstanding issues with current event-handling implementations:
EventHandler connects the event source and target object at the object levelEventListener connects the event source and target objects at the method level using a predefined listener classGenericListener connects the event source and target objects at the method level by dynamically creating a custom listener implementation
at runtime
To improve readability of the article, I have chosen to present a very simple UI implementation. Let's walk through it using
a simple program that displays two toggling buttons in a Frame. The program also handles the system-close event to dispose of the Frame. The same example is presented for each of the utility classes listed above. The following three example programs use standard
JDK/AWT classes.
Proxy"