Page History

Wiki MarkupAccording to the The Java Language Specification (JLS), §12.4, "Initialization of Classes and Interfaces" [JLS 2005]:

Initialization of a class consists of executing its static initializers and the initializers for static fields (class variables) declared in the class.

Therefore, the presence of a static field triggers the initialization of a class. However, the initializer of a static field could depend on the initialization of another class, possibly creating an initialization cycle.

The JLS also states in §8 Specification \[[JLS 05|AA. Java References#JLS 05]\], section 8.3.2.1 , "Initializers for Class Variables" [JLS 2005]:

...at At run time, static variables that are final and that are initialized with compile-time constant values are initialized first.

While this statement typically holds, it can be misleading as it does not account for This statement does not apply to instances that use values of static final fields that are initialized at a later stage. Even if Declaring a field is to be static final , is insufficient to guarantee that it is not necessarily initialized at first go.

Noncompliant Code Example

This noncompliant code example contrives to calculate the account balance by subtracting the processing fee from the deposited amount, but fails to do so. The Cycle class object c is instantiated before the deposit field gets initialized. As a result, the constructor Cycle is invoked which computes the balance based on the initial value of deposit (0) rather than the random value. As a result, the balance always remains -10.

According to the Java Language Specification \[[JLS 05|AA. Java References#JLS 05]\], section 12.4 "Initialization of Classes and Interfaces":

Initialization of a class consists of executing its static initializers and the initializers for static fields (class variables) declared in the class.

fully initialized before being read.

Programs in general should—and security-sensitive programs must—eliminate all class initialization cycles.

Noncompliant Code Example (Intraclass Cycle)

This noncompliant code example contains an intraclass initialization cycle: Wiki MarkupThis statement asserts that the presence of a {{static}} field triggers the initialization of a class, however, in this example, a recursive attempt is being made to initialize the class already. Because such recursive attempts are ignored by the JVM, the default value of {{deposit}} is {{0}} during the initialization. \[[Bloch 05|AA. Java References#Bloch 05]\]

public class Cycle {
  private final int balance;
  private static final Cycle c = new Cycle();
  private final int balance;
  private static final int deposit =  (int) (Math.random() * 100); //random Random deposit

  public Cycle() {
    balance = deposit - 10; //subtract Subtract processing fee
  }

  public static void main(String[] args) {
    System.out.println("The account balance is: " + c.balance);	
  }
}

The Cycle class declares a private static final class variable, which is initialized to a new instance of the Cycle class. Static initializers are guaranteed to be invoked once before the first use of a static class member or the first invocation of a constructor.

The programmer's intent is to calculate the account balance by subtracting the processing fee from the deposited amount. However, the initialization of the c class variable happens before the runtime initialization of the deposit field because it appears lexically before the initialization of the deposit field. Consequently, the value of deposit seen by the constructor, when invoked during the static initialization of c, is the initial value of deposit (0) rather than the random value. As a result, the balance is always computed to be -10.

Step 3 of the detailed initialized procedure described in JLS §12.4.2 [JLS 2014] permits implementations to ignore the possibility of such recursive initialization cycles.

Compliant Solution (Intraclass Cycle)

This compliant solution changes the initialization order of the class Cycle so that the fields meant to be used in computations get duly initialized. As initialization cycles can become insidious when many classes are involved, proper care must be taken to inspect the control floware initialized without creating any dependency cycles. Specifically, the initialization of c is placed lexically after the initialization of deposit so that it occurs temporally after deposit is fully initialized.

public class Cycle {
  private final int balance;
  private static final int deposit =  (int) (Math.random() * 100); //random Random deposit
  private static final Cycle c = new Cycle();  //inserted Inserted after initialization of required fields
  public Cycle() {
    balance = deposit - 10; //subtract Subtract processing fee
  }

  public static void main(String[] args) {
    System.out.println("The account balance is: " + c.balance);	
  }
}

Such initialization cycles become insidious when many fields are involved, so it is important to ensure that the control flow lacks such cycles.

Although this compliant solution prevents the initialization cycle, it depends on declaration order and is consequently fragile; later maintainers of the software may be unaware that the declaration order must be maintained to preserve correctness. Consequently, such dependencies must be clearly documented in the code.

Noncompliant Code Example

...

(Interclass Cycle)

This noncompliant code example uses an inner class that extends the outer class. The outer class in turn, uses the static instance of the inner class. This results in a circular initialization issue \[[Findbugs 08|AA. Java References#Findbugs 08]\].

public class CircularClassInit {
  static class InnerClassSingleton extends CircularClassInit {
    static InnerClassSingleton singleton = new InnerClassSingleton();
  }
  static CircularClassInit foo = InnerClassSingleton.singleton;
}

Compliant Solution

This compliant solution removes the instance of the inner class from the outer class.

public class CircularClassInit {
  static class InnerClassSingleton extends CircularClassInit {
    static InnerClassSingleton singleton = new InnerClassSingleton();
  }
}

...

noncompliant code example declares two classes with static variables whose values depend on each other. The cycle is obvious when the classes are seen together (as here) but is easy to miss when viewing the classes separately.

class A {
  public static final int a = B.b + 1;
  // ...
}

class B {
  public static final int b = A.a + 1;
  // ...
}

The initialization order of the classes can vary, causing computation of different values for A.a and B.b. When class A is initialized first, A.a will have the value 2, and B.b will have the value 1. These values will be reversed when class B is initialized first.

Compliant Solution (Interclass Cycle)

This compliant solution breaks the interclass cycle by eliminating the dependency of A on B:

class A {
  public static final int a = 2;
  // ...
}

class B {
  public static final int b = A.a + 1;
  // ...
}

With the cycle broken, the initial values will always be A.a = 2 and B.b = 3 regardless of initialization order.

Noncompliant Code Example

The programmer in this noncompliant code example attempts to initialize a static variable in one class using a static method in a second class, but that method in turn relies on a static method in the first class:

class A {
  public static int a = B.b();
  public static int c() { return 1; }
}
 
class B {
  public static int b() { return A.c(); }
}

This code correctly initializes A.a to 1, using the Oracle JVM, regardless of whether A or B is loaded first. However, the JLS does not guarantee A.a to be properly initialized. Furthermore, the initialization cycle makes this system harder to maintain and more likely to break in surprising ways when modified.

Compliant Solution

This compliant solution moves the c() method into class B, breaking the cycle:

class A {
  public static int a = B.b();
}
 
class B {
  public static int b() { return B.c(); }
  public static int c() { return 1; }
}

Risk Assessment

Initialization cycles may lead to unexpected results.

Automated Detection

...

TODO

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

Other Languages

This rule appears in the C++ Secure Coding Standard as DCL14-CPP. Do not make assumptions about the order of global variable initialization across translation units.

References

...

Tool	Version	Checker	Description
CodeSonar	Include Page CodeSonar_V CodeSonar_V	JAVA.STRUCT.UA JAVA.STRUCT.UA.DEFAULT	Useless Assignment (Java) Useless Assignment to Default (Java)
Parasoft Jtest	Include Page Parasoft_V Parasoft_V	CERT.DCL00.ACD	Ensure that files do not contain cyclical dependencies
PVS-Studio	Include Page PVS-Studio_V PVS-Studio_V	V6050
SonarQube	Include Page SonarQube_V SonarQube_V	S2390	Classes should not access their own subclasses during initialization

Related Guidelines

Bibliography

...

...

...

...

...

...

...

...

...

Image Added Image Added Image Added Interfaces|http://java.sun.com/docs/books/jls/third_edition/html/execution.html#12.4] Puzzle 49: Larger Than Life \[[MITRE 09|AA. Java References#MITRE 09]\] [CWE ID 665|http://cwe.mitre.org/data/definitions/665.html] "Improper Initialization"49. Miscellaneous (MSC)      49. Miscellaneous (MSC)      MSC01-J. Avoid memory leaks