Tips 'N Tricks: Debug with anonymous inner classes
Use anonymous inner classes for easy debugging
SummaryBy Norbert Ehreke
Anonymous inner classes are mostly used for event handling in Java. However they can also prove useful for debugging purposes. This article explains how anonymous inner classes can be used for easier debugging. (400 words; January 2, 2006)
Printer-friendly version |
Mail this to a friend
ow can we debug method calls that are not part of our own source code, say a call to
JButton.setEnabled()
? Java provides us with anonymous inner classes, which come in quite handy for this problem.
Usually, when we derive a class, we can override existing methods by providing a new one:
public class MyButton extends JButton {
public void setVisible( boolean visible ) {
// Rolling our own visibility
}
}
After instantiating buttons of type MyButton
, any call to setVisible()
will be handled by the code above. The problem is we do not want to declare a whole new class just to override one method, especially when the number of instantiations is limited. Anonymous inner classes let us override methods on the fly at the time of instantiation.
If we just want to roll our own visibility logic in one specific JButton
, we just write the method as we declare the button:
JButton myButton = new JButton() {
public void setVisible( boolean visible ) {
// Rolling our own visibility
}
};
What happened here? The code between the curly braces declares the method setVisible()
and overrides the one from JButton
, but only for myButton
. We have not altered the JButton
class, we have not declared a new class, we have just given one special JButton
its own visibility logic.
In object-oriented terminology, myButton
is an object of an unnamed, hence anonymous, class derived from JButton
.
When is overriding a method and creating an anonymous class on the fly useful? If you code with Swing, you have seen and coded such a mechanism before when you added an event listener, say an ActionListener
, to a GUI element. Now, imagine we have a big class with a bunch of buttons, where one button magically appears and disappears. We want to know why this problem occurs. Use the code above and set a breakpoint in the body of the setVisible
method. Then, as we run our program, the breakpoint will stop us just at the right place. With a look at the stack trace, we find the culprit that called setVisible()
unexpectedly and be able fix the problem.
Anonymous inner classes prove helpful for debugging those classes where the source code is unavailable. Even when source code is available, setting a breakpoint in heavily used methods, such as setVisible()
, might be cumbersome because we'll run into it for every instance of the class that implements setVisible()
. Anonymous inner classes allow surgical debugging for one specific instance.
|
Printer-friendly version |
Mail this to a friend
About the author
Norbert Ehreke is a senior development lead at Impetus Unternehmensberatung GmbH, a consulting company in Frankfurt, Germany. He is responsible for its framework development and has been involved in several Perl-, Java-, and C#-oriented projects. He studied at the Technical University (TU) in Berlin, Germany; the University of Maryland in College Park, Maryland; and at the Eidgenoessische Technische Hochschule in Zurich, Switzerland. He earned a master's degree in systems engineering from TU Berlin. His research interests include object-oriented programming (Java, Ruby, Perl, and C#). In his spare time he likes mountain biking, cooking, and the movies.
- For an introduction to anonymous inner classes, read "Classes Within Classes," Jeff Friesen (JavaWorld, February 2002):
http://www.javaworld.com/javaworld/jw-02-2002/jw-0201-java101.html
- Browse the Core Java section of JavaWorld's Topical Index:
http://www.javaworld.com/channel_content/jw-core-index.shtml