Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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

...

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.3.2.1, "Initializers for Class Variables" [JLS 2005]:

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

This statement does not apply to instances that use values of static final fields that are initialized at a later stage. Declaring a field to be static final is insufficient to guarantee that it is fully initialized before being read.

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

Noncompliant Code Example (

...

Intraclass Cycle)

This noncompliant code example contains an intra-class intraclass initialization cycle.:

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

  public Cycle() {
    balance = deposit - 10; // 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.

...

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 are 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.

...

Such initialization cycles become insidious when many fields are involved. Consequently, 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 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.

...

The initialization order of the classes can vary and, consequently, cause 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 inter-class interclass cycle by eliminating the dependency of A on B.:

Code Block
bgColor#ccccff
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.

...

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.:

Code Block
bgColor#ffcccc
langjava
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 that 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.

...

Initialization cycles may lead to unexpected results.

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

DCL00-J

low

Low

unlikely

Unlikely

medium

Medium

P2

L3

Automated Detection

ToolVersionCheckerDescription
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.ACDEnsure 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

 


...