I did something similar. I made a custom Action subclass; a simple version of it is:
This makes it easy to define a new Action quickly, and get good standardized error handling for any exceptions which you failed to catch
before they reached the action listener. (See my last post (Oct 25) in
this thread for more about exception handling here; "catch Exception" is a simplification.) Since JButtons and JMenus can be constructed from Actions, it becomes easy to make controls in just a few lines. My StandardAction also has a few other conveniences, like constructors that make it easier to associate a parent Window and tooltip text (short description) with a given Action, as well as the usual Icon. But as far as the event listening part - I actually haven't had a need for any listeners other than ActionListener, so that's the only event listener class I've coded. Actions work for buttons and menu items; I haven't needed anything else. Well, there was exactly one place where I wanted a MouseListener to detect double clicks on a table - but since it only occurred in one place, I just created a StandardAction for the response action, and made a MouseListener which simply forwards calls to the Action:
In addition to the StandardAction class, I have a Controls utility class which has some methods to set up other controls quickly, like a JButton or JMenuItem with a mnemonic. It's quite easy once you've got the Action, since it already has a name, Icon, and short description. (Hmmm... I should add the mnemonic to the StandardAction; dunno why they didn't support that in the first place.)
So, the point is: I agree that it can be useful to create a few custom classes to simplify event handlers and controls. But you probably don't need to create very many, if you're careful. Remember that Sun also likes to see standard solutions. Every time you create a custom class, i's something that a junior programmer hasn't seen before, and will require time to understand. So if you have one or two custom classes that you use frequently and they significantly reduce the complexity of the rest of your code, that's good, because it's worth the time for other programmers to look at your custom class and understand it. But if you've got five different event litener classes that are only used once, that may not be so good, because it takes time to understand each one. (And you will have to document each one too.) So, I think this is a good idea, but try to design your classes so you don't need too many of these custom GUI classes.