Inner Classes

Java lets you define one class inside the body of another. The class written inside is called a nested class. When you write one class inside another, you face a choice that is easy to make by habit and easy to get wrong: should the nested class be static or non-static? Both forms are legal, and both compile. The difference shows up only when the nested class's code needs something that belongs to a particular object of the containing class.

This article focuses on the non-static form, which has its own name: the inner class. A non-static nested class is not simply a class that happens to sit inside another class. It is tied to objects of the surrounding class, and that tie determines what the inner class can see and what it cannot. As you read, keep one question in mind: when an inner class needs a value that belongs to a particular outer object, where does that value come from? The answer explains almost everything about how inner classes work.

Start with an ordinary non-static member. Even though its source code is written inside the class definition, it is not really part of the class as a single shared thing. A non-static field or method describes what each object created from the class will contain. A non-static inner class follows the same pattern. Its source code sits inside the containing class, but its existence is tied to individual objects. The right picture is not one inner class for the outer class, but an inner class attached to each outer object.

The following example is an original illustration written to make this association visible. The outer class Counter has a private counter and a label. Its inner class Incrementer increments the counter and prints it. A separate static nested class Helper is included for comparison, and it does not touch any outer instance data. Read the code first and think about what each outer object's counter will look like after the calls.

The diagram shows the key consequence. The two inner objects come from the same class definition, but each one is attached to a different outer object. ia works with Counter A's count and label, and ib works with Counter B's. Two inner-class copies in two different containing objects refer to different instance variables, so they behave differently whenever those variables hold different values.

The word logically matters. A helpful way to reason about inner classes is to imagine that every object of the containing class carries its own copy of the nested class. An object does not physically contain a second copy of the compiled code for the nested class. What matters is behavior: each copy works with the instance variables and instance methods of the particular outer object it belongs to.

Because each inner copy is attached to its outer object, it can use all of that object's instance methods and instance variables. This access extends to members declared private. An inner class is therefore not restricted the way an unrelated class would be when it tries to read another class's private data. In the Counter example, Incrementer reads and changes count, which is private to Counter, and it can do so because it is part of Counter's structure for each object.

Trace one call. When ia.bump() runs, count++ does not refer to some shared Counter field. It refers to the count of the Counter object that ia is attached to, which is Counter A. Its value goes from 1 to 2. The printed label is also taken from Counter A, which is why the output reads A: 2. The call to ib.bump() uses Counter B's count and label instead, so the two inner objects never interfere with each other.

Once you know that a non-static nested class is tied to an outer object, the choice becomes a practical decision. The rule asks a single question: does this nested class depend on a particular object of the containing class? The question is about dependence, not about how often the nested class is used or how it is named. If the answer is yes, the class must be non-static, because only a non-static inner class is attached to a containing object and can reach that object's instance members. If the answer is no, there is nothing for that attachment to provide, and static is the natural choice.

The reasoning follows from the association already traced. A non-static nested class has an outer object behind it, so it can reach that object's instance data. A static nested class has no such link. If it needs instance data from the containing class, it has no route to that data and must be non-static. If it does not need that data, the link adds nothing, and a static nested class is the natural choice. In the Counter example, Incrementer needs count and label, so it is non-static, while Helper needs neither, so it is static.

Because an inner object is attached to an outer object, creating one requires an outer instance. In the Counter example the expression a.new Incrementer() reads as follows: a supplies the Counter object the new Incrementer will be attached to, the keyword new creates the inner object, and Incrementer names the inner class. Written without an outer object, a bare new Incrementer() has nothing to attach to, which is why it cannot succeed on its own.

The mistakes below come from treating an inner class as if it belonged to the class as a single shared thing, rather than to individual outer objects. Each one is easy to make when writing a quick test or a static main method.