When I run this, I get
So: it works fine for me.
As to your second question: anonymous inner classes can't have static fields of any type. You'd have to show us a working example to illustrate otherwise.
about second: consider adding fields:
to Class2 anonymous descendant. It works.
Btw, thanks for adding main and classes declaration.
Compiling this, I get
intellij idea 7.05, jdk 1.4
Class0.java:18: inner classes cannot have static declarations
private static final Object aa;
final int i;
is not a compile time constant, but the following is
final int i = 10;
Now, now, that is hardly a "nice" way to talk. Please look at this.
Gasan Gouseinov wrote:Ankit, I know what the compile time constant is, ok?
And I hardly think inner classes like this are a beginner's problem. Moving.
Gasan Gouseinov wrote:Ernest, I don't clearly understand what you mean by saying that compile time static members constants treated as a macros. But, you're right, in other words, only string or number literals can be static member constants for anonymous inner class (probably for all inner classes, but I don't know).
The compiler can substitute the value right into the code. So instead of there being the bytecode to fetch the value of the member, there will just be the literal value (or for a String, the code to fetch the literal value directly from the class's constant pool).
Gasan Gouseinov wrote:what I'm trying to say is that is legal to have static member in inner anonymous class only of primitive type or String type, but only of them. Why?!
I believe you would have problems with String were it not a String "literal".
it seems as though static members of a non-static inner class doesn't make sense. Since each instance of the inner class is tied to the instance of its outer class how would you access this static member (I'm actually asking)? Thus this is not permitted at all. However, since compile time constants-- primitives that are given a value when they are declared and then dubbed final--cannot change the compiler can remove ocurrences of the variable and replace it with the value. Static or otherwise seems to make no functional difference in scope as far as I see.
edit: thought too long about my response and Earnest beat me.
Ritchie, about problem complexity, I didn't know, how to determine to which java thread to post, so posted to beginner. (Bcs problem isn't about neuronal networks or nanopipes (sic)).
Ernest, at least, I managed to instantiate some code which is resembling what I have and what produced the problems. And it is turned out that the problem isn't very complex and is obvious in some way. Here is the code which generate the same exceptions, which I had.
so the problem is because of parent constructor wasn't completed, therefore there's no way to run child inner class constructor which will initialize instance fields. I didn't found the best solution for this. Probably, it's to add methods for that fields, which will initialize them if they wasn't. I'll find the solution. The most important thing is that I found the reason of this behavior. Many thanks, guys.
Gasan Gouseinov wrote:I didn't found the best solution for this. Probably, it's to add methods for that fields, which will initialize them if they wasn't.
I don't think there really is a rule or solution that always prevents this kind of problem; you really just have to be aware of the possibility, and avoid it. Many people recommend never calling a non-final method of a class during a constructor, to avoid some similar problems (because if you call a method overridden in the child, the child's members won't have been initialized yet.)
In this case, if you want the child to initialize members of the parent, it'd be best to provide an abstract method named "init()" or something like that, then deliberately call it from the parent constructor before accessing those members; i.e.,
But I run into this kind of problem now and then. The classic version is a JDialog subclass that calls setVisible() in its constructor, so that it automatically shows itself. Great idea, right? Now someone writes a subclass of the subclass -- and the dialog becomes visible before the child class constructor has fully run. This can cause some interesting race conditions!