CODEWITHSUNDEEP
java
nneonneo
nneonneo

Reputation: 179552

Recursive initializer works when I add "this"?

This fails to compile (with an illegal forward reference error), as one would expect:

class test {
    int x = x + 42;
}

But this works:

class test {
    int x = this.x + 42;
}

What's going on? What gets assigned in the latter case?

Upvotes: 35

Views: 905

Answers (3)

NPE
NPE

Reputation: 500673

Summary: Both initializers access a field that's yet to be initialized (and therefore still has the default value of zero). Since this is likely to be a programming error, the language bans some simple forms of such access. However, it does not ban more complex form.

The behaviour is compliant with the JLS, specifically §8.3.2.3. Restrictions on the use of Fields during Initialization

The declaration of a member needs to appear textually before it is used only if the member is an instance (respectively static) field of a class or interface C and all of the following conditions hold:

  • The usage occurs in an instance (respectively static) variable initializer of C or in an instance (respectively static) initializer of C.

  • The usage is not on the left hand side of an assignment.

  • The usage is via a simple name.

  • C is the innermost class or interface enclosing the usage.

The first example satisfies all four conditions and is therefore invalid. The second example doesn't satisfy the third condition (this.x is not a simple name), and is therefore OK.

The overall sequence of events is as follows:

Thus if an initializer refers to a field that appears later in the class definition (or to the field itself), it would see the default value of that other field. This is likely to be be a programming error and is therefore explicitly forbidden by §8.3.2.3.

If you circumvent §8.3.2.3 by, for example, using this. to forward-refer to a field, you'll see the default value (zero for int). Thus the following is well-defined and is guaranteed to set x to 42:

class test {
    int x = this.x + 42;
}

Upvotes: 17

ZhongYu
ZhongYu

Reputation: 19682

It is too difficult to discover and forbid all accesses to x during x's initialization. For example

int x = that().x;                |    int x = getX();
                                 |
Test that(){ return this; }      |    int getX(){ return x; }

The spec stops at "access by simple name" and does not try to be more comprehensive.

In another section, "Definite Assignment", the spec does the similar thing. For example

public class Test
{
    static final int y;
    static final int z = y;  // fail, y is not definitely assigned 
    static{ y = 1; }
}

public class Test
{
    static final int y;
    static final int z = Test.y;  // pass... because it's not a simple name
    static{ y = 1; }
}

Interestingly, "Definite Assignment" specifically mentions that this.x is equivalent to x

(or, for a field, the simple name of the field qualified by this)

this clause could be added to the section quoted by NPE as well.

  • the usage is via a simple name (or a simple name qualified by this)

But in the end, it is impossible at compile time to analyze all possible usages/accesses to a field.

Upvotes: 18

Grzegorz Olszewski
Grzegorz Olszewski

Reputation: 1418

In the first case compiler tries to evaluate expression 'x + 42' but fails because x is not initialized.

In the second case expression 'this.x + 42' is evaluated at runtime (because of 'this' keyword), when x is already initialized and has value 0.

Upvotes: 1

Related Questions