Non-static initializers run after constructors, causing confusion

Question

Here are two Java classes, where class testinit2 extends class testinit1. testinit2 has an initializer and overrides the setaaa method of testinit1. What is surprising us is that the initializer in testinit2 is run AFTER the constructor of testinit1 is run. This means that the call in testinit1 constructor setaaa which actually runs the overridden method in testinit2 is completely blown away by the subsequent run of the initializer in testinit2
In other words we expected the value of testinit2.aaa2 to be "new", but instead it is "old"
Does this seem to work as the spec intended????
/* Class A */
import java.util.*;
class testinit1
public String aaa1 = "old";
public testinit1 () {
System.out.println("inside testinit1 constructor");
this.setaaa("new");
public void setaaa(String newval) {
System.out.println("inside testinit1.setaaa");
aaa1 = newval;
/* Class B */
import java.util.*;
class testinit2 extends testinit1
public String aaa2 = "old";
public testinit2 () {
// super();
System.out.println("ckpt3: aaa2 is " +aaa2);
System.out.println("inside testinit2 constructor");
public void setaaa(String newval) {
System.out.println("inside testinit2.setaaa");
aaa1 = newval;
System.out.println("ckpt1: aaa2 is " +aaa2);
aaa2 = newval;
System.out.println("ckpt2: aaa2 is " +aaa2);

Answer 1

But wouldn't that imply that the superclass must know
how its being used? It doesn't know that the method
has been overridden by a subclass. This seems like a
perfectly normal thing to do. I'm not ranting, just
seems like a lot of people could get bitten by this
behavior.Correct, it doesn't know. That's why you shouldn't be calling that method. The point is that you shouldn't make it possible in the first place for subclasses to override methods that might be called whilst the object is under construction.
Sure, people get bitten by this, but thre's not much that can be done about it, so the best they can do is learn from their mistakes.
If the compiler could stop this from happening, then (off the top of my head, without much thought about it, so I might be wrong), the Halting Problem would be solvable. Hence, by contradiction, there's nothing that can be done and we're stuck with it.
Of course, you could carefully document exactly what methods your superclass calls from its constructor, and in what order it calls them, and then you could maybe work around your problem, but I certainly wouldn't recommend it - you would likely be setting yourself up for a fall some time further down the line.
Your best option here is most probably to change your design.