> If I refactor the following class into one below it, should i make the
> below nested class static?
[code elided}
> I'm guessing it should be static so that i can call 'a.setGap(new
> A.Gap());'.
You shouldn't be guessing, and the syntax implied by your choice should
not be your guiding principle. To answer the question intelligently,
you need to understand the difference between making a nested class
static and not.
If a nested class is not static, then every instance has a containing
instance of the containing class. The inner object can access the
containing object's variables and invoke its methods, even the private
ones. There are other implications as well that we probably do not need
to go into at the moment.
If a nested class is static, then it can refer to all its containing
class' static members, including the private ones, but it is not
associated with any particular instance of the containing class. As
access to static members is not usually a big concern, the role of the
containing class is largely to provide a namespace with finer
granularity than a package.
In general, it is usually better to make a nested class static if it
does not depend on a particular instance.
> If so, under what circumstances should i make it non static and call a
> 'a.setGap(a.new Gap());' instead? If i were to do this and the
> constructor accepts a Gap object as one of the parameter, then it's a
> problem since 'a' doesn't exist yet.
You are correct: you cannot pass an inner class instance to the
constructor of its own containing instance. You can pass parameters by
which the constructor can create the inner instance, however. If you
find yourself wanting to do this, though, then you probably have a class
that should be static.
> Also, if most of the time nested classes are static, can i simply put it
> in its own class rather than making it nested if the nested class
> does'nt access any of the enclosing class's variables?
Yes, you certainly can. If the class represents something that is
meaningful in contexts other than the containing class, then it is
probably better to make it a top-level class. If the nested class
represents something that is only meaningful in the context of the
containing class, however, then it makes sense to use a nested class,
even if it doesn't rely on the containing class' members. This all is a
matter of style, however.

Signature
John Bollinger
jobollin@indiana.edu