Return to Revisions

You are correct in assuming that the attribute access available to non-static inner classes leads to high coupling, hence to lower code quality, and (non-anonymous and non-local) inner classes should generally be static.

Design implications of decision to make inner class non-static are laid out in Java Puzzlers, Puzzle 90 (bold font in below quote is mine):

Whenever you write a member class, ask yourself, Does this class really need an enclosing instance? If the answer is no, make it static. Inner classes are sometimes useful, but they can easily introduce complications that make a program difficult to understand. They have complex interactions with generics (Puzzle 89), reflection (Puzzle 80), and inheritance (this puzzle). If you declare Inner1 to be static, the problem goes away. If you also declare Inner2 to be static, you can actually understand what the program does: a nice bonus indeed.

In summary, it is rarely appropriate for one class to be both an inner class and a subclass of another. More generally, it is rarely appropriate to extend an inner class; if you must, think long and hard about the enclosing instance. Also, prefer static nested classes to non-static. Most member classes can and should be declared static.

^{If you're interested, a more detailed analysis of Puzzle 90 is provided in this answer at Stack Overflow.}

It is worth noting that above is essentially an extended version of the guidance given in Java Classes and Objects tutorial:

Use a non-static nested class (or inner class) if you require access to an enclosing instance's non-public fields and methods. Use a static nested class if you don't require this access.

So, the answer to the question you asked in other words per tutorial is, the only convincing reason to use non-static is when access to an enclosing instance's non-public fields and methods is required.

Tutorial wording is somewhat broad (this may be the reason why Java Puzzlers make an attempt to strengthen it and narrow it down). In particular, directly accessing enclosing instance fields has never been really required in my experience - in the sense that alternative ways like passing these as constructor / method parameters always turned easier to debug and maintain.

Overall, my (quite painful) encounters with debugging inner classes directly accessing fields of enclosing instance made strong impression that this practice resembles use of global state, along with known evils associated with it.

Of course, Java makes it so that damage of such a "quasi global" is contained within enclosing class, but when I had to debug particular inner class, it felt like such a band aid didn't help to reduce pain: I still had to keep in mind "foreign" semantic and details instead of fully focusing on analysis of a particular troublesome object.

For the sake of completeness, there may be cases where above reasoning doesn't apply. For example, per my reading of map.keySet javadocs, this feature suggests tight coupling and as a result, invalidates arguments against non-static classes:

Returns a Set view of the keys contained in this map. The set is backed by the map, so changes to the map are reflected in the set, and vice-versa...

Not that above would somehow make involved code easier to maintain, test and debug mind you, but it at least could allow one to argue that complication matches / is justified by intended functionality.