see if you can figure out this 'anomaly'

Please download, compile, and run the two attachments. Tell me if you can explain this 'anomaly'.

I post this more as a curiocity than a need to solve a problem (the second attachment, judging by the title, would suggest I've found a solution). It makes me wonder what the java run-time environment (or maybe the compiler) is doing in this case. Regardless of the fact that there's a simple way to remedy it, it seems to me (in my limited state of Java expertise) that there really shouldn't be an error to begin with.

Because super is run first, then all variables are defined as per the class definition, then the rest of the constructor runs. Since you do not give the instance variable a value in the "no-error" you do not overwrite the value given in the "super" call. Since you do give the instance variable a value in the "error" version you overwrite the value defined in the super call. This is the main reason why all methods called from a constructor should be private and/or final.

If you walk through the stuff in a debugger you would see this.

Quote:

---

Originally Posted by gib65

Please download, compile, and run the two attachments. Tell me if you can explain this 'anomaly'.

I post this more as a curiocity than a need to solve a problem (the second attachment, judging by the title, would suggest I've found a solution). It makes me wonder what the java run-time environment (or maybe the compiler) is doing in this case. Regardless of the fact that there's a simple way to remedy it, it seems to me (in my limited state of Java expertise) that there really shouldn't be an error to begin with.

---

There is no anomaly, it is just your lack of understanding how the jvm initializes objects: just before the body of a constructor is executed a superclass constructor is executed (this applies recursively), next all explicit member variables are initialized and only then the body of the ctor is executed. All the while the 'virtual function table' (a C++ ism) is already set up so a superclass ctor can call a method implemented in a subclass (a very bad thing, as already mentioned).

kind regards,

Jos

Okay, now I understand a bit more about the Java run-time environment than I used to.