The Essence of OOP using Java, Anonymous Classes

Baldwin explains anonymous classes from a practical viewpoint, including a comparison between anonymous classes and local classes.

Published:  January 5, 2004
By Richard G. Baldwin

Java Programming Notes # 1640

Preface

This series of lessons is designed to teach you about the essence of Object-Oriented Programming (OOP) using Java.

The first lesson in the series was entitled The Essence of OOP Using Java, Objects, and Encapsulation.  The previous lesson was entitled The Essence of OOP using Java, Local Classes.

You may find it useful to open another copy of this lesson in a separate browser window.  That will make it easier for you to scroll back and forth among the different figures and listings while you are reading about them.

For further reading, see my extensive collection of online Java tutorials at Gamelan.com. A consolidated index is available at www.DickBaldwin.com.

Preview

What can you include in a class definition?

There are several different kinds of items that can be included in a class definition.  As you learned in the earlier lessons in this series, the list includes:

Can also contain other class definitions

As you also learned in previous lessons, a class definition can also contain the following four kinds of inner classes:

The previous two lessons explained member classes and local classes.  This lesson will explain anonymous classes.  The next lesson will explain nested top-level classes and interfaces.

(Note that it is questionable whether a nested top-level class or interface should be referred to as an inner class, because an object of a nested top-level class can exist in the absence of an object of the enclosing class.  Regardless of whether the term inner class applies, a nested top-level class is defined within the definition of another class, so its definition is internal to the definition of another class.)

What is an anonymous class?

I'm going to begin my discussion with a quotation from one of my favorite authors, David Flanagan, author of Java in a Nutshell.

"An anonymous class is essentially a local class without a name."

If you have read the previous lesson, you should know quite a lot about local classes at this point in time.  Continuing with Flanagan's words,

"Instead of defining a local class and then instantiating it, you can often use an anonymous class to combine these two steps...  an anonymous class is defined by a Java expression, not a Java statement.  This means that an anonymous class definition can be included within a larger Java expression..."

As you will see from the sample program in this lesson, anonymous class definitions are often included as arguments to method calls.

As is the case for an object of a member class or a local class (discussed in previous lessons), an object of an anonymous class must be internally linked to an object of the enclosing class.

Thus, an anonymous class is truly an inner class, because an object of the anonymous class cannot exist in the absence of an object of the enclosing class.

What about an anonymous interface?

Interfaces defined within classes are implicitly static.  This means that they are always top-level.  There is no such thing as a member interface, a local interface, or an anonymous interface.

Why use anonymous classes?

As with local classes, objects instantiated from anonymous classes share many of the characteristics of objects instantiated from member classes.  However, in some cases, an anonymous class can be defined closer to its point of use than would be possible with a member class or a local class.  Once you become accustomed to the somewhat cryptic syntax used with anonymous classes, this can often lead to improved code readability.

Probably the most important benefit of anonymous classes has to do with accessing the members of enclosing classes.  Just like with member classes and local classes, methods of an anonymous class have direct access to all the members of the enclosing classes, including private members.  Thus the use of anonymous classes can often eliminate the requirement to connect objects together via constructor parameters.

In addition, although not demonstrated in this lesson, as with local classes, objects of anonymous classes have access to final local variables that are declared within the scope of the anonymous class.

Can be particularly useful when ...

An anonymous class can be particularly useful in those cases where

Purpose of this lesson

This lesson explains anonymous classes from a practical viewpoint, including a comparison between anonymous classes and local classes.

Anonymous classes versus local classes

Once again, according to David Flanagan,

"...an anonymous class behaves just like a local class, and is distinguished from a local class merely in the syntax used to define and instantiate it."

Unlike a local class, however, an anonymous class cannot define a constructor.  An anonymous class can define an instance initializer, which can provide some of the benefits of a constructor.

(I discussed instance initializers in detail in an earlier lesson entitled The Essence of OOP using Java, Instance Initializers.  As you may recall, a primary shortcoming of an instance initializer as compared to a constructor is that an instance initializer cannot accept incoming parameters.)

Restrictions on the use of anonymous classes

Because an anonymous class has no name, and the definition and instantiation of the class appear in a single expression, only one instance of each anonymous class can be created.  If you need more than one instance of the class, you should probably use a local class, a member class, or a top-level class instead.

As mentioned above, it is not possible to define constructors for anonymous classes.  If you need to use a constructor when you instantiate the class, you should probably use a local class, a member class, or a top-level class instead.

As with member classes and local classes, anonymous classes cannot contain static members.

As with local variables and local classes, anonymous classes cannot be declared public, protected, private, or static.  In fact, no modifiers can be specified in the definition of an anonymous class.

Smoke and mirrors

As I told you in my earlier lessons on local classes, the methods in an anonymous class don't really have access to local variables and method parameters.  Rather, when an object of the anonymous class is instantiated, copies of the final local variables and method parameters referred to by the object's methods are stored as instance variables in the object.  The methods in the object of the anonymous class really access those hidden instance variables.

Thus, the local variables and method parameters accessed by the methods of the local class must be declared final to prevent their values from changing after the object is instantiated.

There are some additional activities involving smoke and mirrors taking place behind the scenes when you define and instantiate an anonymous class.  Generally speaking, this involves the automatic generation of code to cause things to behave as they do.  The good news is that you don't have to write that extra code, and you don't have to maintain it.  The extra code is written for you, and if you modify your class structure, the extra code is automatically modified accordingly.

You can read about the code that is automatically generated in my earlier lessons on local classes and member classes.

Syntax for anonymous classes

Before getting into actual code in the sample program, I want to explain the syntax used to define and instantiate an anonymous class.

The definition and instantiation of an anonymous class uses one or the other of the two expressions shown in Figure 1.

new className(optional argument list){classBody}

new interfaceName(){classBody}
Figure 1

Usually, this expression is included inside a larger overall expression, such as an argument to a method call.

What does the first expression mean?

Here is how I usually explain this syntax to my students.  The first expression in Figure 1 starts out fairly normal, but becomes cryptic very quickly.  This expression instantiates a new object from an unnamed and previously undefined class, which automatically extends the class named className, and which cannot explicitly implement any interfaces.  The body of the new class is given by classBody.

The result of executing this expression is that a new class that extends className is defined, a new object of the new class is instantiated, and the expression is replaced by a reference to the new object.

Example usage

If this expression appears as the right operand of an assignment operator, the object's reference is saved in the left operand of the assignment operator.   If the expression appears as an argument in a method call, the object's reference is passed to the method.  If the expression appears in some other form of larger overall expression, the object's reference is handed over to the surrounding expression to be used appropriately.

What about instantiating an interface?

The second expression in Figure 1 starts out weird.  To my knowledge, there is no other situation in Java where you apply the new operator to the name of an interface.  From the beginning, you have been told that you cannot instantiate an object of an interface.  (An interface is implicitly abstract and it doesn't have a constructor, not even a default constructor.)  However, you can instantiate an object of a class that implements none, one, or more interfaces.

The correct interpretation of the second expression in Figure 1 is as follows.   This expression instantiates a new object from an unnamed and previously undefined class, which automatically implements the interface named interfaceName, and automatically extends the class named Object.   The class can explicitly implement one, and only one interface, and cannot extend any class other than Object.  Once again, the body of the new class is given by classBody.

As in the case of the first expression in Figure 1, the result of executing this expression is that a new class that implements interfaceName is defined, a new object of the new class is instantiated, and the expression is replaced by a reference to the new object.  That reference is handed over to the surrounding expression to be used appropriately.

What about constructor parameters?

As mentioned earlier in this lesson, since the new class doesn't have a name, it isn't possible to define a constructor for the new class.  According to Flanagan,
"Any arguments you specify between the parentheses following the superclass name in an anonymous class definition are implicitly passed to the superclass constructor."
Thus, it is possible to define an anonymous class that extends a class whose constructor requires parameters, and to pass those parameters to the superclass constructor when the anonymous class is instantiated.

The parentheses following interfaceName in the second expression in Figure 1 must always be empty.  In this case, the superclass is always Object, which never expects constructor parameters.

Enough talk, let's see some code

The paragraphs that follow will explain a program named InnerClasses08, which is designed specifically to illustrate anonymous classes, and to compare anonymous classes with local classes.  I will discuss the program in fragments.  A complete listing of the program is provided in Listing 10 near the end of the lesson.

Discussion and Sample Code

When the program is executed, it produces the GUI shown in Figure 2.  I will refer back to this figure during the discussion of the program.

Program GUI

Figure 2  Program GUI

Class file names

This program consists of a total of six classes:
When compiled, the program produces the class files shown in Figure 3.  

GUI$1$BaldButton.class
GUI$1.class
GUI$2.class
GUI$3.class
GUI.class
InnerClasses08.class
Figure 3

As you will see later, the file named GUI$1$BaldButton.class represents the local class.  The three files named GUI$1.class, GUI$2.class, and GUI$3.class represent anonymous classes.  The two remaining files represent top-level classes.
(As you can see, the anonymous classes are not truly anonymous, since the files that represent them must have names.  Generally, however, the establishment of the individual names is beyond the control of the programmer, and the names are not known to the program in a way that makes it possible to refer to them by name.)
Program structure and behavior

This program is designed to illustrate the use of local classes and anonymous classes in a very practical way. It illustrates one implementation of a local class and three different implementations of anonymous classes. The program compares the local class with an anonymous class designed to accomplish the same purpose.  The program also illustrates the use of instance initializers as an alternative to constructors.

A local class

The program defines and uses a local class to instantiate an object to handle mouse clicked events on a button with low-level event handling. This class uses a constructor to enable mouse events on a new extended Button class. It also uses a constructor to display the name of the class file.

An anonymous class to compare with the local class

The program also defines and uses an anonymous class to instantiate an object to handle mouse clicked events on a button with low-level event handling. This class uses an instance initializer to enable mouse events on a new extended Button class. It also uses an instance initializer to display the name of the class file.  This class and the local class described above provide a direct comparison between the use of local classes and anonymous classes to serve the same purpose.

An anonymous class that implements an interface

The program illustrates the use of an anonymous class, which implements the MouseListener interface, to instantiate an object to handle mouse clicked events using the source-listener event model (sometimes referred to as the delegation event model or the JavaBeans event model). The anonymous class uses an instance initializer to display the name of the class file.

An anonymous class that extends an existing class

The program illustrates the use of an anonymous class, which extends the WindowAdapter class, to instantiate an object to handle window events fired by the close button in the upper-right corner of the Frame object shown in Figure 2.  This class also uses the source-listener event model, and uses an instance initializer to display the name of the class file.

The screen output

The program produces the screen output shown in Figure 4 when
Local class name: GUI$1$BaldButton
Anonymous class B name: GUI$1
Anonymous class C name: GUI$2
Anonymous window listener class name: GUI$3
buttonA clicked
buttonB clicked
buttonC clicked
Close button clicked
Figure 4

When the close button is clicked, the program produces the last line of text in Figure 4 and terminates.

I will identify the code that produces each line of output text in the discussion of the program that follows.

The controlling class

The controlling class for the program is shown in Listing 1.

public class InnerClasses08 {
  public static void main(String[] args){
    new GUI();
  }//end main
}//end class InnerClasses08

Listing 1

As you can see, the controlling class is very simple, with the main method instantiating an object of the GUI class.  This results in the GUI that is pictured in Figure 2.

Local and anonymous classes inside GUI constructor

The local class and the three anonymous classes are defined inside the constructor for the GUI class.
(Recall that local classes and anonymous classes are defined inside code blocks, which often place them inside methods and constructors, but you can also place them inside static initializer blocks and instance initializers.)
The first four lines of the output text in Figure 4 are produced by constructors and instance initializers in the local and anonymous classes.  Therefore, those four lines of text are produced when the new object of the GUI class is instantiated.

The GUI class

As is often the case, the GUI class used to create the visual GUI shown in Figure 2 consists solely of a constructor.  Basically, this constructor places three buttons in the frame and registers event handlers on the buttons and on the frame.  Once the GUI object is constructed and appears on the screen, all further activity in the program occurs under control of the event handlers associated with the buttons and the frame.
(You can learn more about event handling by reviewing my online tutorial lessons at http://www.dickbaldwin.com/tocmed.htm.)
The GUI constructor

The GUI class, and the constructor for that class begin in Listing 2. 

class GUI extends Frame{
  public GUI(){//constructor
    setLayout(new FlowLayout());
    setSize(250,75);
    setTitle("Copyright 2003 R.G.Baldwin");

Listing 2

As you can see, the GUI class extends Frame, so that an object of the class is a frame.

The constructor code shown in Listing 2 simply sets values for the layout, size, and title properties of the frame.

The BaldButton class

The BaldButton class, whose definition begins in Listing 3, is a local class that extends Button.  This class extends the Button class to make it possible to override the processMouseEvent method in order to handle mouse events that are fired by the button.  This is a form of low-level event handling, which will be contrasted with source-listener event handling later in the program.

Listing 3 shows the constructor for the BaldButton class.

    class BaldButton extends Button{
      BaldButton(String text){//constructor
        enableEvents(AWTEvent.MOUSE_EVENT_MASK);
        setLabel(text);
        System.out.println("Local class name: " +
                           getClass().getName());
      }//end constructor

Listing 3

Enable mouse events

The most important code in the constructor is the statement that enables mouse events on the button.  If you are unfamiliar with the enableEvents method, you should look it up in the Sun documentation.

Briefly, this method must be invoked on the button to cause the overridden processMouseEvent method to be invoked later when the button fires a mouse event.

The remaining constructor code

The remaining code in the constructor
The screen output

Construction of the button by the code in Listing 3 causes the text shown in Figure 5 to appear on the screen.  This is how I was able to identify the name of the class file that represents the local class in my earlier discussion of class file names.

Local class name: GUI$1$BaldButton
Figure 5

We will see later that this button will be added as the leftmost button in the GUI shown in Figure 2.

The processMouseEvent method

Continuing with the constructor for the BaldButton class, Listing 4 shows the overridden processMouseEvent method for an object of the BaldButton class.

      public void processMouseEvent(
                                   MouseEvent e){
        if (e.getID() ==
                       MouseEvent.MOUSE_CLICKED){
          System.out.println("buttonA clicked");
        }//end if

        //The following is required of overridden
        // processMouseEvent method.
        super.processMouseEvent(e);
      }//end processMouseEvent
    }//end class BaldButton

    //Add button to Frame
    add(new BaldButton("A"));
Listing 4

This method is invoked each time an object instantiated from this class fires a mouse event.  That is why I refer to the method as an event handler for the button.

Different kinds of mouse events

A button can fire a variety of different kinds or subcategories of mouse events: 
In this case, I elected to ignore all but MOUSE_CLICKED.  This subcategory of mouse event occurs when a mouse button is pressed and then released.

Thus the code in the event handler of Listing 4 first confirms that the event was of the MOUSE_CLICKED variety, and if so, it displays a message that matches the fifth line of text in the output shown in Figure 4.

Invoke processMouseEvent on the superclass

Without getting into the details of why this is required, I'm simply going to tell you that when you use this low-level event model to handle events, your overridden processMouseEvent method must call the same method in the superclass, passing the incoming parameter of type MouseEvent as a parameter to the superclass version of the method.

Add a button to the frame

The last statement in Listing 4 instantiates a new BaldButton object, setting the text on the face of the button to A, and adds that new object to the frame.  Because the layout property of the frame has been set to FlowLayout, and because this is the first component added to the frame, this button appears as the leftmost button in the GUI shown in Figure 2.

Could instantiate multiple buttons of this type

Although I instantiated the button object as an anonymous object in this case, that wasn't necessary.  Using this local class, I could instantiate more than one object of this type, saving the object's references in reference variables of the appropriate type.  Later we will see that this is not possible for anonymous classes.

It is interesting to note, however, that with this event handle model, if I were to instantiate multiple buttons of this type, the same processMouseEvent method would be invoked no matter which of the buttons fired a mouse event.  If I wanted different behavior as a result of the different buttons firing mouse events, I would have to write code inside the processMouseEvent method to deal with that issue.  The source-listener event model that I will illustrate later doesn't suffer from that restriction.

An anonymous inner class for low-level event handling

Listing 5 shows the beginning of an anonymous class to perform low-level event handling similar to that shown in Listing 4.  This code defines an anonymous inner class, which extends Button, and which has mouse events enabled.  I provided this class primarily for comparison with the local class named BaldButton.  This class is an anonymous alternative to the local BaldButton class.

    add(new Button("B")
      {//Begin class definition
        {//Instance initializer
          enableEvents(
                      AWTEvent.MOUSE_EVENT_MASK);
          System.out.println(
                     "Anonymous class B name: " +
                           getClass().getName());
        }//end instance initializer

Listing 5

An argument to the add method

Note that the definition of this anonymous class appears as an argument to the add method for the frame.  Thus, the anonymous object instantiated from the anonymous class is added as the second (middle) button in Figure 2.

Extends the Button class

Note also that this form of anonymous class implicitly extends the Button class.  Once again, this makes it possible to override the processMouseEvent method belonging to the Button class.

An instance initializer

As I mentioned earlier in this lesson, it is not possible to define a constructor for an anonymous class.  However, it is possible to define an instance initializer.  This class defines an instance initializer, which
The screen output

Therefore, the instantiation of this anonymous object causes the text shown in Figure 6 to appear on the screen.  About all you can tell by looking at this class name is that it is the name of a file that represents an anonymous class.

Anonymous class B name: GUI$1
Figure 6

Overridden processMouseEvent method

The remaining code in the anonymous class definition is shown in Listing 6.

        public void processMouseEvent(
                                   MouseEvent e){
          if (e.getID() ==
                       MouseEvent.MOUSE_CLICKED){
            System.out.println(
                              "buttonB clicked");
          }//end if

          //Required of overridden
          // processMouseEvent method.
          super.processMouseEvent(e);
        }//end processMouseEvent
      }//end class definition
    );//end add method call

Listing 6

Basically, the remaining code consists of an overridden processMouseEvent method, and the curly braces, parentheses, and semicolon necessary to complete the expression and the statement.

Same code as before

The code in this overridden processMouseEvent method is essentially the same as that shown for the local class in Listing 4, except that it produces a different message on the screen when the user clicks the button.

Clicking the middle button in Figure 2 produces the screen output shown by the sixth line in Figure 4.

Implementing a listener interface

Now I'm going to switch from low-level event handling to source-listener event handling.  With this event handling model
Instantiating and registering a MouseListener object

The code to accomplish this begins in Listing 7.  Listing 7 begins by instantiating a new Button object.
(Note that with this event model, it is not necessary to extend the Button class, because it is not necessary to override methods belonging to the Button object.)
After instantiating a new Button object, the code in Listing 7 invokes the addMouseListener method to register a MouseListener object on that button.  The argument to the addMouseListener method must be a reference to an object instantiated from a class that implements the MouseListener interface.

    Button buttonC = new Button("C");

    buttonC.addMouseListener(new MouseListener()
      {//begin class definition
        //Instance initializer
        {System.out.println(
                     "Anonymous class C name: " +
                          getClass().getName());}

Listing 7

Instantiate the listener object

In this case, that listener object is created by writing an expression to instantiate an anonymous object from an anonymous class and placing that expression as an argument to the addMouseListener method.

Implement the MouseListener interface

The definition of the anonymous class in this example uses the syntax that implements an interface.

An instance initializer

As before, an instance initializer is used to get and display the name of the class file that represents the anonymous class.  Thus, when the new anonymous object of the anonymous class is instantiated, the text shown in Figure 7 appears on the screen.  Note the similarity of this class file name to that shown earlier in Figure 6.  The names of the two class files differ only with respect to a number that is provided by the compiler to guarantee that each class file name is unique.

Anonymous class C name: GUI$2
Figure 7

Implementing the interface

Whenever a class implements an interface, it must provide a concrete definition for each of the methods declared in the interface, even if some of those methods are empty.

Continuing with the definition of the anonymous class, Listing 8 provides definitions for all five of the methods declared in the MouseListener interface.  Four of those methods are defined as empty methods.

        public void mouseClicked(MouseEvent e){
          System.out.println("buttonC clicked");
        }//end mouseClicked

        //All interface methods must be defined
        public void mousePressed(MouseEvent e){}
        public void mouseReleased(MouseEvent e){}
        public void mouseEntered(MouseEvent e){}
        public void mouseExited(MouseEvent e){}

      }//end class definition
    );//end addMouseListener call

    add(buttonC);//add button to frame

Listing 8

Separation of event subcategories

One of the major differences between the low-level event model discussed earlier and the source-listener model being discussed here has to do with where the separation between the different subcategories (mouseClicked, mousePressed, mouseReleased, etc.) of a given event type is accomplished

In the low-level model, the separation must be accomplished by code in the overridden event handler method, such as with the if statement in the processMouseEvent method defined in Listing 6.

In the source-listener model, the separation is accomplished before the event handler method is invoked, and a specific event handler method, such as the mouseClicked method is invoked on the listener object.

When the button fires a mouse event ...

In this case, whenever the button fires a MouseEvent of the mouseClicked subcategory, the mouseClicked method defined in Listing 8 will be invoked, causing the seventh line of text in Figure 4 to appear on the screen.

Whenever the button fires a MouseEvent of one of the other subcategories, one of the empty methods defined in Listing 8 will be invoked.  This method will return immediately, doing nothing but wasting a little computer time.
(In case you are wondering what happened to the mouseMoved and mouseDragged methods, they are defined in the MouseMotionListener interface instead of the MouseListener interface.)
Add the button to the frame

Finally, the last statement in Listing 8 adds the new button to the frame as the rightmost button in Figure 2.

A disclaimer

I wrote this code the way that I did in Listing 8 to illustrate an anonymous class that implements an interface.  In real life, I would probably cause the anonymous class to extend the MouseAdapter class and override the mouseClicked method instead of implementing the MouseListener interface.  That would eliminate the requirement for me to define the four empty methods in Listing 8.

Extending the WindowAdapter class

The above disclaimer provides a perfect lead-in to the definition of the anonymous class shown in Listing 9.

    addWindowListener(new WindowAdapter()
      {//begin class definition
        //Instance initializer
        {System.out.println(
             "Anonymous window listener class " +
               "name: " + getClass().getName());}

        public void windowClosing(WindowEvent e){
          System.out.println(
                         "Close button clicked");
          System.exit(0);
        }//end windowClosing
      }//end class definition
    );//end addWindowListener

    setVisible(true);

  }//end constructor
}//end GUI class

Listing 9

Registering a WindowListener on the frame

The code in Listing 9 instantiates an anonymous object of an anonymous class, which extends the WindowAdapter class.  That anonymous object is registered as a WindowListener on the frame by passing the object's reference to the addWindowListener method belonging to the frame.
(The addWindowListener method requires an incoming parameter of type WindowListener.  This is satisfied by the fact that the WindowAdapter class implements the WindowListener interface.  Thus, an object instantiated from a class that extends WindowAdapter can also be treated as type WindowListener.)
The screen output

This anonymous class definition uses an instance initializer to get and display the name of the class that represents the anonymous class.  Thus, when the anonymous object of the anonymous class is instantiated, the text shown in Figure 8 appears on the screen.

Anonymous window listener class name: GUI$3
Figure 8

Class file names

In an earlier lesson explaining member classes, I told you that it is possible to examine the names of the class files that represent the member classes and to determine quite a lot about the structure of the program in terms of which classes are members of which other classes.  However, in the case of local classes and anonymous classes, about all that you can determine from the name of the class file is that the file either represents a local class or represents an anonymous class (see the summary of class named in Figure 3).

The windowClosing method

The code in Listing 9 overrides the windowClosing method inherited from the WindowAdapter class.

Clicking the close button with the X in the upper right hand corner of Figure 2 causes the windowClosing method to be invoked on any WindowListener objects that have been registered on the frame.  In this case, the overridden windowClosing method in Listing 9 cases the last line of text in Figure 4 to be displayed on the screen.

Following that, the overridden windowClosing method invokes the System.exit method to terminate the program.

The remaining code

The remaining code in Listing 9
The GUI remains on the screen until terminated

Once the constructor is executed, the GUI simply remains on the screen waiting for someone to click one of the buttons or to click the close button in the upper right corner of the frame.  When these buttons are clicked, the event handlers are invoked, causing text such as that shown in Figure 9 to appear on the screen.

buttonA clicked
buttonB clicked
buttonC clicked
Close button clicked
Figure 9

Simple event handlers

In this demo program, the event handlers simply display messages on the screen, and in the case of the close button, terminate the program.  In a real world program, the behavior of the event handlers would likely be much more substantive, but the overall skeleton of the program need not be any different from that illustrated here.

Run the Program

At this point, you may find it useful to compile and run the program shown in Listing 10 near the end of the lesson.

Summary

In addition to a number of other items, a class definition can contain:
Member classes and local classes were explained in previous lessons.  This lesson explains anonymous classes.  The next lesson will explain nested top-level classes and interfaces.

Although there are some differences, an anonymous class is very similar to a local class without a name.

Instead of defining a local class and then instantiating it, you can often use an anonymous class to combine these two steps.

An anonymous class is defined by a Java expression, not a statement.  Therefore, an anonymous class definition can be included within a larger overall Java expression.

Anonymous class definitions are often included as arguments to method calls, or as the right operand to assignment operators.

An object of an anonymous class must be internally linked to an object of the enclosing class.

There is no such thing as an anonymous interface, a local interface, or a member interface.

An anonymous class can often be defined very close to its point of use.  Once you become accustomed to the somewhat cryptic syntax used with anonymous classes, this can lead to improved code readability.

Probably the most important benefit of anonymous classes has to do with accessing the members of enclosing classes.  As with member classes and local classes, methods of an anonymous class have direct access to all the members of the enclosing classes, including private members.  Thus the use of anonymous classes can sometimes eliminate the requirement to connect objects together via constructor parameters.

In addition, objects of anonymous classes have access to final local variables that are declared within the scope of the anonymous class.

An anonymous class can be particularly useful in those cases where

An anonymous class cannot define a constructor.  However, it can define an instance initializer.  Any arguments that you specify between the parentheses following the superclass name in an anonymous class definition are implicitly passed to the superclass constructor.

Only one instance of an anonymous class can be created.

As with member classes and local classes, anonymous classes cannot contain static members.

As with local variables and local classes, anonymous classes cannot be declared public, protected, private, or static.

What's Next?

The next lesson in this series will explain top-level nested classes.

Complete Program Listing

A complete listing of the program discussed in this lesson is show in Listing 10 below.

/*File InnerClasses08.java
Copyright 2003 R.G.Baldwin

This program is designed to illustrate the use
of local classes, and anonymous classes.  It
illustrates three different implementations of
anonymous classes.  It also illustrates the use
of instance initializers as an alternative to
constructors.

Illustrates use of local class to instantiate
object to handle mouse clicked event with
low-level event handling.  This class uses
constructor to enable mouse events on a new
extended Button class.  Also uses constructor
to display the class file name.

Illustrates use of anonymous class to instantiate
object to handle mouse clicked event with
low-level event handling.  This class uses an
instance initializer to enable mouse events on a
new extended Button class.  Also uses instance
initializer to display name of class file.

Illustrates use of anonymous class, which
implements MouseListener interface, to
instantiate object to handle mouse clicked event
using source-listener event model.  Uses instance
initializer to display name of class file.

Illustrates use of anonymous class, which extends
WindowAdapter class, to instantiate object to
handle window events fired by the close button in
the upper-right corner of a Frame object, using
source-listener event model.  Uses instance
initializer to display name of class file.

This program produces the following class files
when compiled:

GUI$1$BaldButton.class
GUI$1.class
GUI$2.class
GUI$3.class
GUI.class
InnerClasses08.class

The program produces the following output when
the program is started, each button is clicked
once in succession, and then the close button
in the upper-right corner of the Frame is
clicked:

Local class name: GUI$1$BaldButton
Anonymous class B name: GUI$1
Anonymous class C name: GUI$2
Anonymous window listener class name: GUI$3
buttonA clicked
buttonB clicked
buttonC clicked
Close button clicked

Tested using JDK 1.4.1 under Win
************************************************/

import java.awt.*;
import java.awt.event.*;

public class InnerClasses08 {
  public static void main(String[] args){
    new GUI();
  }//end main
}//end class InnerClasses08
//=============================================//

class GUI extends Frame{

  public GUI(){//constructor
    setLayout(new FlowLayout());
    setSize(250,75);
    setTitle("Copyright 2003 R.G.Baldwin");

    //Local class w/mouse events enabled. The new
    // class extends Button, and uses low-level
    // event handling to handle mouse clicked
    // events on the button.
    class BaldButton extends Button{
      BaldButton(String text){//constructor
        enableEvents(AWTEvent.MOUSE_EVENT_MASK);
        setLabel(text);
        //Display the name of the class file
        System.out.println("Local class name: " +
                           getClass().getName());
      }//end constructor

      //This is the event handling method.
      public void processMouseEvent(
                                   MouseEvent e){
        if (e.getID() ==
                       MouseEvent.MOUSE_CLICKED){
          System.out.println("buttonA clicked");
        }//end if
        //The following is required of overridden
        // processMouseEvent method.
        super.processMouseEvent(e);
      }//end processMouseEvent
    }//end class BaldButton

    //Add button to Frame
    add(new BaldButton("A"));


    //This code defines an anonymous Inner Class
    // w/mouse events enabled.  The new class
    // extends Button.  This class uses low-level
    // event handling to handle mouse clicked
    // events on the button.  This is an
    // anonymous alternative to the local class
    // defined above.
    add(new Button("B")
      {//Begin class definition
        {//Instance initializer
          enableEvents(
                      AWTEvent.MOUSE_EVENT_MASK);
          System.out.println(
                     "Anonymous class B name: " +
                           getClass().getName());
        }//end instance initializer

        //Override the inherited
        // processMouseEvent method.
        public void processMouseEvent(
                                   MouseEvent e){
          if (e.getID() ==
                       MouseEvent.MOUSE_CLICKED){
            System.out.println(
                              "buttonB clicked");
          }//end if
          //Required of overridden
          // processMouseEvent method.
          super.processMouseEvent(e);
        }//end processMouseEvent
      }//end class definition
    );//end add method call


    Button buttonC = new Button("C");
    //Anonymous inner class that implements
    // MouseListener interface
    buttonC.addMouseListener(new MouseListener()
      {//begin class definition
        //Instance initializer
        {System.out.println(
                     "Anonymous class C name: " +
                          getClass().getName());}

        public void mouseClicked(MouseEvent e){
          System.out.println("buttonC clicked");
        }//end mouseClicked

        //All interface methods must be defined
        public void mousePressed(MouseEvent e){}
        public void mouseReleased(MouseEvent e){}
        public void mouseEntered(MouseEvent e){}
        public void mouseExited(MouseEvent e){}

      }//end class definition
    );//end addMouseListener call

    add(buttonC);//add button to frame


    //Use an anonymous class to register a window
    // listener on the Frame.  This class extends
    // WindowAdapter
    addWindowListener(new WindowAdapter()
      {//begin class definition
        //Instance initializer
        {System.out.println(
             "Anonymous window listener class " +
               "name: " + getClass().getName());}

        public void windowClosing(WindowEvent e){
          System.out.println(
                         "Close button clicked");
          System.exit(0);
        }//end windowClosing
      }//end class definition
    );//end addWindowListener

    setVisible(true);

  }//end constructor

}//end GUI class
//=============================================//

Listing 10

Copyright 2003, Richard G. Baldwin.  Reproduction in whole or in part in any form or medium without express written permission from Richard Baldwin is prohibited.

About the author

Richard Baldwin is a college professor (at Austin Community College in Austin, Texas) and private consultant whose primary focus is a combination of Java, C#, and XML. In addition to the many platform and/or language independent benefits of Java and C# applications, he believes that a combination of Java, C#, and XML will become the primary driving force in the delivery of structured information on the Web.

Richard has participated in numerous consulting projects, and he frequently provides onsite training at the high-tech companies located in and around Austin, Texas.  He is the author of Baldwin's Programming Tutorials, which has gained a worldwide following among experienced and aspiring programmers. He has also published articles in JavaPro magazine.

Richard holds an MSEE degree from Southern Methodist University and has many years of experience in the application of computer technology to real-world problems.

baldwin@DickBaldwin.com

-end-