static vs. non-static nested classes

Nested classes come in two flavors: static and non-static or inner classes. I understand that instances of an inner class can see the members of it's class's owner, even when they're private. But apart from this practicality, what is the difference between the two flavors? For example, what is the difference on lower code-levels? And, how should I choose between a static or an inner class when both are possible?

A static class is shared between all instances of the enclosing class (thus static fields are shared between all instances), while each instance has its own version of a non-static inner class. Non-static inner classes are stored with the enclosing object (rather than class) and can only be accessed via an instance.

Non-static inner classes are best used in data structures, e.g. to represent the nodes in a tree.

There are good examples of non-static
inner classes.

In all of my reading, the subject of
static inner classes is a dead issue.
I can recall only brief paragraphs
which logically argue that although
a static inner class is possible, it is
pointless.

This recollection of mine is vague.
I also am interested in seeing
examples where the use of static
inner classes is necessary.

Quote:

---

I also am interested in seeing
examples where the use of static
inner classes is necessary.

---

I'm thinking that it's never necessary, but perhaps there are times when it makes things more easily comprehended doing it this way. For instance nesting enums (which per language specifications are always static whether declared static or not) sometimes make them more understandable.

If you have a Card class, it kind of makes intuitive sense to me to nest the Suit and Rank enums inside of the Card class. I can't even explain fully why I prefer this, but it seems to me that these concepts are dependent on there being a Card class, that you can't have one without the other. Is this necessary? of course not, but I still would want these logical constructs tied very closely together.

I did some reading up and found out the following:

(Some of the info below is basic knowledge. It's there to draw a complete picture. The third point is the answer to my initial question.)

1. There are two types of classes: top-level and nested classes.
2. There are two types of nested classes: static and non-static nested classes.
3. A static nested class is actually the same as a top-level class. The only difference with top-level classes is in namespace resolution: a static nested class can be marked private for example, and when used from outside the owning class it should be referred to in the following manner: "OwningClass.NestedClass" as opposed to simply "NestedClass".
4. Non-static nested classes are called inner classes. (Static nested classes are not inner classes!)
5. There are three types of inner classes: member, method-local and anonymous inner classes.

In general, use a static inner class if you can. If your code works with the inner class static, then having the hidden reference to the parent object is pointless and could cause some subtle problems (e.g. with serialisation or garbage collection).

That's a good rule of thumb, but mind the terminology: an inner class is by definition not static. The term "inner class" is defined as a non-static nested class.

Non-static member classes are useful for returning instances that access the instance data of the enclosing class instance, e.g. adapters, such as iterators in collection classes. If the member class doesn't require access to the enclosing instance, it should always be made static.

First, a "nested" class is static, and an "inner" class is not.

The advantage of an inner class is that it has full access to the members of the "outer" class (anonymous inner classes, because they are defined within a method, lose this ability). Inner classes are very useful as event handlers and for implementing component framework classes (say, Swing JTable component classes) that really don't need to be visible outside the class.

I use nested classes when I need a class that is independent of any instance but that has no real meaning apart from the class in which it is nested. I will put enumerations inside a class when the enumeration defines a property of the class, for Exceptions that are thrown by the class, and when doing Swing development.

Nested classes can always be defined as separate classes, but that requires separate source files, and the connection between the class and its "owner" is not apparent until the developer looks into the class.