Tarun Oohri wrote:1. Why it is that we can not define anything static inside the regular inner class (not talking about the static inner class).
I suspect it's to keep things simple, although there may also be some structural reasons. But think of it this way: Why do we define
static fields to begin with? Generally so that we have something that is globally accessible, either from inside a class (if it's
private) or the public at large (if it's
public).
Since nested classes are fully visible to their enclosing class, you can't
hide a
static field by putting it in an inner class, and since there's only ever going to be 1 copy of it, it really doesn't matter whether you define it in the inner class or it's outer one.
There might, however, be a reason for defining a static
constant inside an inner class, the most obvious of which is readability - ie, it just makes more sense to name the field in the context of the inner class, because that's where it has a meaning. But, as I hope you know, constants are
final.
It may also be worth mentioning that true inner classes (ie,
non-static nested classes) are really quite rare, and are usually used to hide an internal implementation, so they're usually
private. Some
Maps, for example, use them to hold their keys as a
Set, which is what you get when you call the
keySet() method.
Static nested classes, on the other hand, are much more common, and are just like a regular class - it just happens to be defined inside another one, usually because that's the only place where it makes sense. A good example of a class like that is
AbstractMap.SimpleEntry which, as it turns out, implements a nested
interface:
Map.Entry.
HIH
Winston