Why doesn't this statement throw a StackOverflowError?

Question

I just saw this weird piece of code in another question. I thought it would result in a StackOverflowError being thrown, but it doesn't...

public class Node {
    private Object one;
    private Object two;
    public static Node NIL = new Node(Node.NIL, Node.NIL);

    public Node(Object one, Object two) {
        this.one = one;
        this.two = two;
    }
}

I thought it was going to thow an exception, because of the Node.NIL referencing itself to build.

I can't figure it out why it does not.

What I would expect is that the `NIL` field is constructed as it it was declared as `new Node(null, null)`, because when the constructor is called, `Node.NIL` hasn't been set to anything yet. — khelwood, Jan 30 '17 at 09:44
Please never use this in production code. It can provide a nice trivia, but I would consider this to be deliberate obfuscation. — chi, Jan 30 '17 at 12:05
@chi i won't for sure, but i saw this piece of code on another question, and i was confused about how it could work. — Anthony Raymond, Jan 30 '17 at 12:17
Not sure why you thought this would explode. How would the stack trace look like? — xehpuk, Jan 30 '17 at 22:03
I thought because `Node.NIL` was given to the constructor of `Node.NIL`, but Eran's answer made it clear. — Anthony Raymond, Jan 30 '17 at 22:05

Eran · Accepted Answer · 2017-01-30T14:07:51.653

100

NIL is a static variable. It is initialized one time, when the class is initialized. When it is initialized, a single Node instance is created. The creation of that Node doesn't trigger creation of any other Node instances, so there is not infinite chain of calls. Passing Node.NIL to the constructor call has the same effect as passing null, since Node.NIL is not yet initialized when the constructor is called. Therefore public static Node NIL = new Node(Node.NIL, Node.NIL); is the same as public static Node NIL = new Node(null, null);.

If, on the other hand, NIL was an instance variable (and wasn't passed as an argument to the Node constructor, since the compiler would have prevented you from passing it to the constructor in that case), it would be initialized every time an instance of Node was created, which would create a new Node instance, whose creation would initialize another NIL instance variable, leading to infinite chain of constructor calls that would end in StackOverflowError.

edited Jan 30 '17 at 14:07

answered Jan 30 '17 at 09:39

Eran

387,369
54
702
768

Thanks, you made it clearer, the way it works is still odd to me. But at least i understand why it works this way. – Anthony Raymond Jan 30 '17 at 09:43
5

If `NIL` was an instance variable, it would not compile with the error `Cannot reference a field before it is defined`. – Florian Genser Jan 30 '17 at 14:03
@FlorianGenser Good point. I wrote this part before noticing that `Node.NIL` was passed to the constructor. – Eran Jan 30 '17 at 14:05
3

java.awt.Color is actually a good demonstration of static variables in action. It has a bunch of different colors, like Color.BLUE, which also contains references to all the other colors... This dazzled me back when I first started in Java. – sfdcfox Jan 30 '17 at 15:33
Thanks for that @sfdcfox i'll take a look on this. – Anthony Raymond Jan 30 '17 at 19:12

score 28 · Answer 2 · answered Jan 30 '17 at 09:44

The variable NIL is first given the value null and then initialised once top to bottom. It isn't a function and isn't defined recursively. Any static field you use before it is initialised has the default value and your code is the same as

public static Node {
    public static Node NIL;

    static {
        NIL = new Node(null /*Node.NIL*/, null /*Node.NIL*/);
    }

    public Node(Object one, Object two) {
        // Assign values to fields
    }
}

This is no different to writing

NIL = null; // set implicitly
NIL = new Node(NIL, NIL);

If you defined a function or method like this, you would get a StackoverflowException

Node NIL(Node a, Node b) {
    return NIL(NIL(a, b), NIL(a, b));
}

score 20 · Answer 3 · answered Jan 30 '17 at 09:49

The key to understand why it doesn't cause infinite inititialization is that when the class Node is being initialized, the JVM keeps track of it and avoids re-initialization during a recursive reference to the class within its original initialization. This is detailed in this section of the language spec:

Because the Java programming language is multithreaded, initialization of a class or interface requires careful synchronization, since some other thread may be trying to initialize the same class or interface at the same time. There is also the possibility that initialization of a class or interface may be requested recursively as part of the initialization of that class or interface; for example, a variable initializer in class A might invoke a method of an unrelated class B, which might in turn invoke a method of class A. The implementation of the Java Virtual Machine is responsible for taking care of synchronization and recursive initialization by using the following procedure.

So while the static initializer is creating the static instance NIL, the reference to Node.NIL as part of the constructor call does not re-execute the static initializer again. Instead it just references whatever value the reference NIL has at that time, which is null in this case.

Why doesn't this statement throw a StackOverflowError?

3 Answers3