— Scott McNealy, Sun Microsystems Chairman, President and ceo

I don’t see the importance of the event object 
that’s passed to the event call-back methods. If 
somebody calls my mousePressed method, what 
other info would I need?
A: 
A lot of the time, for most designs, you don’t 
need the event object. It’s nothing more than a little 
data carrier, to send along more info about the event. 
But sometimes you might need to query the event for 
specific details about the event. For example, if your 
mousePressed() method is called, you know the mouse 
was pressed. But what if you want to know exactly 
where the mouse was pressed? In other words, what if 
you want to know the X and Y screen coordinates for 
where the mouse was pressed? 
Or sometimes you might want to register the same 
listener with multiple objects. An onscreen calculator, 
for example, has 10 numeric keys and since they all do 
the same thing, you might not want to make a separate 
listener for every single key. Instead, you might 
register a single listener with each of the 10 keys, and 
when you get an event (because your event call-back 
method is called) you can call a method on the event 
object to find out who the real event source was. In 
other words, which key sent this event.
Sharpen your pencil
windowClosing()
actionPerformed()
itemStateChanged()
mousePressed()
keyTyped()
mouseExited()
focusGained()
check box
text field
scrolling list
button
dialog box
radio button
menu item
Widgets
Event methods
Each of these widgets (user interface objects) are the 
source of one or more events. Match the widgets with 
the events they might cause. Some widgets might be a 
source of more than one event, and some events can be 
generated by more than one widget.