text: The.
  Nested types have no universally adopted nomenclature. The term
  "inner class" is commonly used.
  Sometimes, however, inner class is used to refer to a nonstatic
  member class, local class, or anonymous class, but not a static
  member type. Although the terminology for describing nested types is
  not always clear, the syntax for working with them is, and it is
  usually clear from context which kind of nested type is being
  discussed.
  Now we'll describe each of the four kinds of nested
  types in greater detail. Each section describes the features of the
  nested type, the restrictions on its use, and any special Java syntax
  used with the type. These four sections are followed by an
  implementation note that explains how nested types work under the
  hood.
  A static member
  type is much like a regular top-level type. For
  convenience, however, it is nested within the namespace of another
  type. Example 3-7
  // The static keyword is optional: all nested interfaces are static type is defined as a
  static member of a containing type. Any type
  (class, interface, enumerated type, or annotation type) may be
  defined as a static member of any other type. Interfaces, enumerated
  types, and annotation types are implicitly static, whether or not the
  static keyword appears in their definition.
  A static member type is like the other static members of a class:
  static fields and static methods. Like a class method, a static
  member type is not associated with any instance of the containing
  class (i.e., there is no this object). A static
  member type does, however, have access to all the
  static members (including any other static member
  types) of its containing type. A static member type can use any other
  static member without qualifying its name with the name of the
  containing type.
  A static member type has
  access to all static members of its containing type, including
  private members. The reverse is true as well: the
  methods of the containing type have access to all members of a static
  member type, including the private members. A
  static member type even has access to all the members of any other
  static member types, including the private members
  of those types.
  Top-level types can be declared with or without the
  public modifier, but they cannot use the
  private and protected
  modifiers. Static member types, however, are members and can use any
  access control modifiers that other members of the containing type
  can. These modifiers have the same meanings for static member types
  as they do for other members of a type. In Example 3-7, the Linkable interface is
  declared public, so it can be implemented by any
  class that is interested in being stored on a
  LinkedStack. Recall that all members of interfaces
  (and annotation types) are implicitly public, so
  static member types nested within interfaces or annotation types
  cannot be protected or private.
  A
  static member type cannot have the same name as any of its enclosing
  classes. In addition, static member types can be defined only within
  top-level types and other static member types. This is actually part
  of a larger prohibition against static members of
  any sort within member, local, and anonymous classes.
  In code
  outside the containing class, a static member type is named by
  combining the name of the outer type with the name of the inner type
  (e.g., LinkedStack.Linkable). You can use the
  import directive to import a static member type:
  import pkg.LinkedStack.Linkable; // Import a specific nested type
  import pkg.LinkedStack.*; // Import all nested types of LinkedStack
  In Java 5.0 and later, you can also use the import
  static directive to import a static member type. See Section 2.10 in Chapter 2 for details on
  import and import static. Note
  that importing a nested type obscures the fact that that type is
  closely associated with its containing type, and it is not commonly
  done.
  A nonstatic member
  class is a class that is declared as a
  member of a containing class or
  enumerated type without the static keyword. If a
  static member type is analogous to a class field or class method, a
  nonstatic member class is analogous to an instance field or instance
  method. Example 3-8 shows how a member class can be
  defined and used. This example extends the previous
  LinkedStack example to allow enumeration of the
  elements on the stack by defining an iterator( )
  method that returns an implementation of the
  java.util.Iterator
  interface. The implementation of this interface
  is defined as a member class. The example uses Java 5.0 generic type
  syntax in a couple of places, but this should not prevent you from
  understanding it. (Generics are covered in Chapter 4.)
  import java.util.Iterator;
  public class LinkedStack {
  // Our static member interface
  public interface Linkable {
  public Linkable getNext();
  public void setNext(Linkable node);
  }
  // The head of the list
  private Linkable head;
  // Method bodies omitted here
  public void push(Linkable node) { ... }
  public Linkable pop() { ... }
  // This method returns an Iterator object for this LinkedStack
  public Iterator<Linkable> iterator() { return new LinkedIterator(); }
  // Here is the implementation of the Iterator interface,
  // defined as a nonstatic member class.
  protected(); }
  }
  }
  Notice how the LinkedIterator class is nested
  within the LinkedStack class. Since
  LinkedIterator is a helper class used only within
  LinkedStack, there is real elegance to having it
  defined so close to where it is used by the containing class.
  Like
  instance fields and instance methods, every instance of a nonstatic
  member class is associated with an instance of the class in which it
  is defined. This means that the code of a member class has access to
  all the instance fields and instance methods (as well as the
  static members) of the containing class, including
  any that are declared private.
  This crucial feature is illustrated in Example 3-8.
  Here is the LinkedStack.LinkedIterator()
  constructor again:
  public LinkedIterator() { current = head; }
  This single line of code sets the current field of
  the inner class to the value of the head field of
  the containing class. The code works as shown, even though
  head is declared as a private
  field in the containing class.
  A nonstatic member class, like any member
  of a class, can be assigned one of three
  visibility levels:
  public, protected, or
  private. If none of these visibility modifiers is
  specified, the default package visibility is used. In Example 3-8, the LinkedIterator class
  is declared protected, so it is inaccessible to
  code (in a different package) that uses the
  LinkedStack class but is accessible to any class
  that subclasses LinkedStack.
  Member classes have three important
  restrictions:
  A nonstatic member class cannot have the same name as any containing
  class or package. This is an important rule, one not shared by fields
  and methods.
  Nonstatic member classes cannot contain any static
  fields, methods, or types, except for constant fields declared both
  static and final.
  static members are top-level constructs not
  associated with any particular object while every member class is
  associated with an instance of its enclosing class. Defining a
  static top-level member within a member class that
  is not at the top level would cause confusion, so it is not allowed.
  Only classes may be defined as nonstatic
  members. Interfaces, enumerated types, and annotation types are all
  implicitly static, even if the static keyword is
  omitted.
  The
  most important feature of a member class is that it can access the
  instance fields and methods in its containing object. We saw this in
  the LinkedStack.LinkedIterator() constructor of
  Example 3-8:
  In this example, head is a field of the
  LinkedStack class, and we assign it to the
  current field of the
  LinkedIterator class. What if we want to make
  these references explicit? We could try code like this:
  public LinkedIterator() { this.current = this.head; }
  This code does not compile, however.
  this.current is fine; it is an explicit reference
  to the current field in the newly created
  LinkedIterator object. It is the
  this.head expression that causes the problem; it
  refers to a field named head in the
  LinkedIterator object. Since there is no such
  field, the compiler generates an error. To solve this problem, Java
  defines a special syntax for explicitly referring to the containing
  instance of the this object. Thus, if we want to
  be explicit in our constructor, we can use the following syntax:
  public LinkedIterator() { this.current = LinkedStack.this.head; }
  The general syntax is
  classname.this, where
  classname is the name of a containing
  class. Note that member classes can themselves contain member
  classes, nested to any depth. Since no member class can have the same
  name as any containing class, however, the use of the enclosing class
  name prepended to this is a perfectly general way
  to refer to any containing instance. This syntax is needed only when
  referring to a member of a containing class that is hidden by a
  member of the same name in the member class.
  When a class shadows or overrides a
  member of its superclass, you can use the keyword
  super to refer to the hidden member. This
  super syntax can be extended to work with member
  classes as well. On the rare occasion when you need to refer to a
  shadowed field f or an overridden method
  m of a superclass of a containing class
  C, use the following expressions:
  C.super.f
  C.super.m()
  As we've seen, every
  instance of a member class is associated with an instance of its
  containing class. Look again at our definition of the
  iterator() method in Example 3-8:
  public Iterator<Linkable> iterator() { return new LinkedIterator(); }
  When a member class
  constructor is invoked like this, the new instance of the member
  class is automatically associated with the this
  object. This is what you would expect to happen and exactly what you
  want to occur in most cases. Occasionally, however, you may want to
  specify the containing instance explicitly when instantiating a
  member class. You can do this by preceding the new
  operator with a reference to the containing instance. Thus, the
  iterator() method shown earlier is shorthand for
  the following:
  public Iterator<Linkable> iterator() { return this.new LinkedIterator(); }
  Let's pretend we didn't define an
  iterator( ) method for
  LinkedStack. In this case, the code to obtain an
  LinkedIterator object for a given
  LinkedStack object might look like this:
  LinkedStack stack = new LinkedStack(); // Create an empty stack
  Iterator i = stack.new LinkedIterator(); // Create an Iterator for it
  The containing instance implicitly specifies the containing class; it
  is a syntax error to explicitly specify the containing class name:
  Iterator i = stack.new LinkedStack.LinkedIterator(); // Syntax error
  One other special piece of Java syntax specifies an enclosing
  instance for a member class explicitly. Before we consider it,
  however, let me point out that you should rarely, if ever, need to
  use this syntax. It is one of the pathological cases that snuck into
  the language along with all the elegant features of nested types.
  As strange as it may seem, it is
  possible for a top-level class to extend a member class. This means
  that the subclass does not have a containing instance, but its
  superclass does. When the subclass constructor invokes the superclass
  constructor, it must specify the containing instance. It does this by
  prepending the containing instance and a period to the
  super keyword. If we had not declared our
  LinkedIterator class to be a
  protected member of
  LinkedStack, we could subclass it. Although it is
  not clear why we would want to do so, we could write code like the
  following:
  // A top-level class that extends a member class
  class SpecialIterator extends LinkedStack.LinkedIterator {
  // The constructor must explicitly specify a containing instance
  // when invoking the superclass constructor.
  public SpecialIterator(LinkedStack s) { s.super(); }
  // Rest of class omitted...
  }
  We've
  just noted that a top-level class can extend a member class. With the
  introduction of nonstatic member classes, two separate hierarchies
  must be considered for any class. The first is the
  inheritance hierarchy, from superclass to
  subclass, that defines the fields and methods a member class
  inherits. The second is the containment
  hierarchy, from containing class to contained class, that
  defines a set of fields and methods that are in the scope of (and are
  therefore accessible to) the member class.
  The two hierarchies are entirely
  distinct from each other; it is important that you do not confuse
  them. This should not be a problem if you refrain from creating
  naming conflicts, where a field or method in a superclass has the
  same name as a field or method in a containing class. If such a
  naming conflict does arise, however, the inherited field or method
  takes precedence over the field or method of the same name in the
  containing class. This behavior is logical: when a class inherits a
  field or method, that field or method effectively becomes part of
  that class. Therefore, inherited fields and methods are in the scope
  of the class that inherits them and take precedence over fields and
  methods by the same name in enclosing scopes.
  A good way to prevent confusion between the class hierarchy and the
  containment hierarchy is to avoid deep containment hierarchies. If a
  class is nested more than two levels deep, it is probably going to
  cause more confusion than it is worth. Furthermore, if a class has a
  deep class hierarchy (i.e., it has many ancestors), consider defining
  it as a top-level class rather than as a
  nonstatic member class.
  A local class is
  declared locally within a block of Java code rather than as a member
  of a class. Only classes may be defined locally: interfaces,
  enumerated types and annotation types must be top-level or static
  member types. nested type.-9 shows how we can modify the
  iterator() method of the
  LinkedStack class so it defines
  LinkedIterator as a local class instead of a
  member class. By doing this, we move the definition of the class even
  closer to where it is used and hopefully improve the clarity of the
  code even further. For brevity, Example 3-9 shows
  only the iterator( ) method, not the entire
  LinkedStack class that contains it.
  // This method returns an Iterator object for this LinkedStack
  public Iterator<Linkable> Iterator() {
  // Here's the definition of LinkedIterator as a local class(); }
  }
  // Create and return an instance of the class we just defined
  return new LinkedIterator();
  } are declared final.
  Local classes are subject to the following
  restrictions:
  The name of a local class is defined only within the block that
  defines it; it can never be used outside that block. (Note however
  that instances of a local class created within the scope of the class
  can continue to exist outside of that scope. This situation is
  described in more detail later in this section.),
  enumerated types, and annotation types could be declared
  final. The addition of local classes in Java 1.1
  required a liberalization in the use of the final
  modifier. As of Java 1.1, final can nonstatic member
  classes, have an enclosing instance that is implicitly passed to all
  constructors of the local class. Local classes can use the same
  this
  syntax as nonstatic member classes to refer explicitly to members of
  enclosing classes. Because local classes are never visible outside
  the blocks that define them, however, there is never a need to use
  the new and super syntax used
  by member classes to specify the enclosing instance explicitly.
  In discussing nonstatic that.[10]
   scopeto.
  The local class MyIntHolder is sometimes called a
  closure. In general terms, a closure is an
  object that saves the state of a scope and makes that scope available
  later. Closures are useful in some styles of programming, and
  different programming languages define and implement closures in
  different ways. Java's closures are relatively weak
  (and some would argue that they are not truly closures) because they
  retain the state of only final variables.. In practice, anonymous
  classes are much more common than local classes. If you find yourself
  defining a short local class and then instantiating it exactly once,
  consider rewriting it using anonymous class syntax, which places the
  definition and use of the class in exactly the same place.
  Consider Example 3-10, which shows the
  LinkedIterator class
  implemented as an anonymous class within the iterator(
  ) method of the LinkedStack class.
  Compare it with Example 3-9, which shows the same
  class implemented as a local class. The generic syntax in this
  example is covered in Chapter 4.
  public Iterator<Linkable> iterator() {
  // The anonymous class is defined as part of the return statement
  return new Iterator<Linkable>() {
  Linkable current;
  // Replace constructor with an instance initializer
  {(); }
  }; //.
  Anonymous classes allow you to define a one-shot class exactly where
  it is needed. Anonymous classes have all the features of local
  classes but use a more concise syntax that can reduce clutter in your
  code.
  Because an anonymous class is just
  a type of local class, anonymous classes and local classes share the
  same restrictions. An anonymous class cannot define any
  static fields, methods, or classes, except for
  static final constants.
  Interfaces, enumerated types, and annotation types cannot be defined
  anonymously. Also, like local classes, anonymous classes cannot be
  public , private,
  protected, or static.
  Since an anonymous class has no name, it is not possible to define a
  constructor for an anonymous class. If your class requires a
  constructor, you must use a local class instead. However, you can
  often use an instance initializer as a substitute for a constructor.
  The syntax for defining an anonymous class combines definition with
  instantiation. }
  Although they are not limited to use with anonymous classes, instance
  initializers were introduced into the language for this purpose. As
  described earlier in this chapter in Section 3.3.4, an instance initializer is
  a block of initialization code contained within curly braces inside a
  class definition. The contents of all instance initializers nested types, the engineers at Sun
  recommend the following formatting rules:
  The opening curly brace should not be on a line by itself; instead,
  it should follow the closing closing parenthesis followed by a semicolon. This extra punctuation
  serves as a flag to the reader that this is not just an ordinary
  block of code and makes it easier to understand anonymous classes in
  a code
  listing.
  The preceding sections explained the
  features and behavior of the four kinds of nested types. Strictly
  speaking, that should be all you need to know about nested types. You
  may find it easier to understand nested types if you understand how
  they are implemented, however.
  Nested types were added in Java 1.1. Despite the dramatic changes to
  the Java language, the introduction of nested types did not change
  the Java Virtual Machine or the Java class file format. As far as the
  Java interpreter is concerned, there is no such thing as a nested
  type: all classes are normal top-level classes. In order to make a
  nested type behave as if it is actually defined inside another class,
  the Java compiler ends up inserting hidden fields, methods, and
  constructor arguments into the classes it generates. You may want to
  use the javap disassembler to disassemble some
  of the class files for nested types so you can see what tricks the
  compiler has used to make the nested types work. (See Chapter 8 for information on
  javap.)
  Recall our first
  LinkedStack example (Example 3-7), which defined a static member interface
  named Linkable. When you compile this
  LinkedStack class, the compiler actually generates
  two class files. The first one is
  LinkedStack.class, as expected. The second class
  file, however, is called
  LinkedStack$Linkable.class. The
  $ in this name is automatically inserted by the
  Java compiler. This second class file contains the implementation of
  the static member interface.
  As we discussed earlier, a static member type can access all the
  static members of its containing class. If a
  static member type does this, the compiler automatically qualifies
  the member access expression with the name of the containing class. A
  static member type is even allowed to access the
  private static fields of its
  containing class. Since the static member type is compiled into an
  ordinary top-level class, however, there is no way it can directly
  access the private members of its container.
  Therefore, if a static member type uses a private
  member of its containing type (or vice versa), the compiler generates
  synthetic non-private access methods and converts
  the expressions that access the private members
  into expressions that invoke these specially generated methods. These
  methods are given the default package access, which is sufficient, as
  the member class and its containing class are guaranteed to be in the
  same package.
  A nonstatic member class is implemented
  much like a static member type. It is compiled into a separate
  top-level class file, and the compiler performs various code
  manipulations to make interclass member access work correctly.
  The most significant difference between a nonstatic member class and
  a static member type is that each instance of a nonstatic member
  class is associated with an instance of the enclosing class. The
  compiler enforces this association by defining a synthetic field
  named this$0 in each member class. This field is
  used to hold a reference to the enclosing instance. Every nonstatic
  member class constructor is given an extra parameter that initializes
  this field. Every time a member class constructor is invoked, the
  compiler automatically passes a reference to the enclosing class for
  this extra parameter.
  As we've seen, a nonstatic member class, like any
  member of a class, can be declared public,
  protected, or private, or given
  the default package visibility. Member classes are compiled to class
  files just like top-level classes, but top-level classes can have
  only public or package access. Therefore, as far as the Java
  interpreter is concerned, member classes can have only public or
  package visibility. This means that a member class declared
  protected is actually treated as a public class,
  and a member class declared private actually has
  package visibility. This does not mean you should never declare a
  member class as protected or
  private. Although the Java VM cannot enforce these
  access control modifiers, the modifiers are stored in the class file
  and conforming Java compilers do enforce them.
  A local class is able to
  refer to fields and methods in its containing class for exactly the
  same reason that a nonstatic member class can; it is passed a hidden
  reference to the containing class in its constructor and saves that
  reference away in a private synthetic field added
  by the compiler. Also, like nonstatic member classes, local classes
  can use private fields and methods of their
  containing class because the compiler inserts any required accessor
  methods.
  What makes local classes different from member classes is that they
  have the ability to refer to local variables in the scope that
  defines them. The crucial restriction on this ability, however, is
  that local classes can reference only local variables and parameters
  that are declared final. The reason for this
  restriction becomes apparent in the implementation. A local class can
  use local variables because the compiler automatically gives the
  class a private instance field to hold a copy of
  each local variable the class uses. The compiler also adds hidden
  parameters to each local class constructor to initialize these
  automatically created private fields. A local
  class does not actually access local variables but merely its own
  private copies of them. The only way this can work correctly is if
  the local variables are declared final so that
  they are guaranteed not to change. With this guarantee, the local
  class can be assured that its internal copies of the variables are
  always in sync with the real local variables.
  Since anonymous classes have no names,
  you may wonder what the class files that represent them are named.
  This is an implementation detail, but Sun's Java
  compiler uses numbers to provide anonymous class names. If you
  compile the example code shown in Example 3-10,
  you'll find that it produces a class file for the
  anonymous class with a name like
  LinkedStack$1.class.