Page History

...

A related error can arise when a programmer declares a static final reference to a mutable object; see VOID OBJ02OBJ50-J. Never conflate confuse immutability of a reference with that of the referenced object for additional information.

Noncompliant Code Example

In this noncompliant code example, class Foo declares a field whose value represents the version of the software. The field is subsequently accessed by class Bar from a separate compilation unit.

Foo.java:

class Foo {
  public static final int VERSION = 1;
  // ...
}

Bar.java:

class Bar {
  public static void main(String[] args) {
    System.out.println("You are using version " + Foo.VERSION);
  }
}

When compiled and run, the software correctly prints

    You are using version 1

But if a developer changes the value of VERSION to 2 by modifying Foo.java and recompiles Foo.java but fails to recompile Bar.java, the software incorrectly prints:

    You are using version 1

Although recompiling Bar.java solves this problem, a better solution is available.

Compliant Solution

According to §13§13.4.9, "final Fields and Constants," of the Java Language Specification [JLS 2005],

...

Foo.java:

class Foo {
  private static final int version = 1;
  public static final String getVersion() {
    return version;
  }

  // ...
}

Bar.java:

class Bar {
  public static void main(String[] args) {
    System.out.println("You are using version " + Foo.getVersion());
  }
}

In this solution, the private version value cannot be copied into the Bar class when it is compiled, consequently preventing the bug. Note that most just-in-time (JIT) code generators can inline the getVersion() method at runtime, so little or no performance penalty is incurred.

Exceptions

DCL04DCL61-EX1EX0: According to §9§9.3, "Field (Constant) Declarations," of the Java Language Specification [JLS 2005], "Every field declaration in the body of an interface is implicitly public, static, and final. It is permitted to redundantly specify any or all of these modifiers for such fields."

DCL04DCL61-EX2EX1: Constants declared using the enum type are permitted to violate this guideline.

DCL04DCL61-EX3EX2: Constants whose value never changes throughout the entire lifetime of the software may be declared as final. For instance, the Java Language Specification recommends that mathematical constants be declared final.

Risk Assessment

Failing to declare mathematical constants static and final can lead to thread-safety issues as well as to inconsistent behaviorDeclaring as final a value that changes over the lifetime of the software may lead to unexpected results.

Automated Detection

Static checking of this guideline is not feasible in the general case.

Related Vulnerabilities

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

Related Guidelines

C Secure Coding Standard: DCL00-C. Const-qualify immutable objects

Bibliography

DCL57-JG. Properly encode relationships in constant definitions      01. Declarations and Initialization (DCL)      DCL05-J. Declare all enhanced for statement loop variables to be final