Simply because they are not in a static context. To instantiate an inner class, there must be an instance of the enclosing class. This fact implies a context that is not static. The inner class object actually has a hidden reference (this) to the enclosing class object. You can declare the inner class as static and get around that problem. But then, you won't be able to access any instance variables because now the context is static.
Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius - and a lot of courage - to move in the opposite direction. - Ernst F. Schumacher
Does the term "inner class" imply that it is anonymous? If so, then Michael's statements seem good enough. However, if an inner class isn't necessarily anonymous, then I don't see any reasons why it can't have static methods. In this case, you would be able to reference static methods with a class name, whereass with an anonymous innder class there is no class name to use to reference static methods. Layne
However, if an inner class isn't necessarily anonymous, then I don't see any reasons why it can't have static methods. Not true. Try creating a named inner class with any static identifier, variable, method or block and see what happens unless it is a constant (static final). JLS Spec 8.1.2 states: An inner class is a nested class that is not explicitly or implicitly declared static. Inner classes may not declare static initializers (�8.7) or member interfaces. Inner classes may not declare static members, unless they are compile-time constant fields (�15.28).
This is going well outside the scope of a "beginner" discussion, but I want to present an accurate picture here. The beginner answer to Fitz's original question is "because the compiler won't let you" - if you want to know why the compiler won't let you, well, read on, but don't say you weren't warned. [MM]: To instantiate an inner class, there must be an instance of the enclosing class. Not true - it is entirely possible to declare an inner class in a static context, in which case there is no enclosing instance. See JLS 8.1.2: "An instance of an inner class I whose declaration occurs in a static context has no lexically enclosing instances." Or try to compile the following:
Even in a static context, an inner class is still not allowed to declare any static members. I think the reason for this is to avoid confusion. Realize that any inner class in a static context is either a local class or an anonymous class. (If it were a member class, it's either static or it isn't; there's no "static context" gray area here.) Consider a local class defined inside a static method, as above. Looking at the code, you may think this class comes into existence when the method is executed, and is subsequently forgotten and eligible for GC after the method completes. (Behind the scenes that's not really what happens, but it's a reasonable guess for something declared locally.) If I execute the method twice, should I get the same inner class the second time, or a different one? That is, if the class had some static member data which is modified during execution of the method, when I run the method a second time, should I see the changed static data, or should it be re-initialized? The answer isn't really clear, IMO. The JLS could have defined an answer, but I believe many programmers would remain very confused over the issue, and this would be a recurring source of bugs. Instead the JLS simply forbids static members of local and anonymous classes, to avoid this confusion. There are similar issues for nonstatic member classes. If you have two different outer class instances, and each has one or more inner class instances associated with it, and those inner classes had "static" data, should the data be shared among all inner instances, or only those associated with the same outer instance? Again, it's too confusing, so Java's designers chose to simply forbid it. If there's some static state info you need to keep track of, put it somewhere in the outer class; don't try to attach it to an inner class.