Page History

...

However, constants that can change over the lifetime of a program should not be declared public final. The JLS Java Language Specification allows implementations to insert the value values of public final fields inline in any compilation unit that reads the field. Consequently, if the declaring class is edited such so that the new version gives a different value for the field, compilation units that read the public final field may could still see the old value until they are themselves re-compiled.

A related error can arise when a programmer declares a static final reference to a mutable object; see guideline OBJ01-J. Do not assume that a final reference makes the referenced object immutable for additional information.

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

...

When compiled and run, the software correctly prints:

    You are using version 1

...

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

5.2 Compliant Solution

According to the Java Language Specification \[[JLS 2005|AA. Bibliography#JLS 05]\], §13.4.9, "{{final}} Fields and Constants" of the Java Language Specification [JLS 2005],

Other than for true mathematical constants, we recommend that source code make very sparing use of class variables that are declared static and final. If the read-only nature of final is required, a better choice is to declare a private static variable and a suitable accessor method to get its value.

...

As a result, the private version value cannot be copied into the Bar class when it is compiled, consequently preventing the bug. Note that most JITs JIT code generators are capable of inlining the getVersion() method at runtime; consequently there is little or no performance penalty incurred.

5.3 Exceptions

*DCL04-EX0*: According to the Java Language Specification \[[JLS 2005|AA. Bibliography#JLS 05]\], §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."

...

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

5.4 Risk Assessment

Failing to declare mathematical constants static and final can lead to thread safety issues, as well as to inconsistent behavior.

5.5 Automated Detection

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

5.6 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

5.7 Bibliography

\[[JLS 2005|AA. Bibliography#JLS 05]\] [§13.4.9|http://java.sun.com/docs/books/jls/third_edition/html/binaryComp.html#13.4.9] "final Fields and Constants", [§9.3|http://java.sun.com/docs/books/jls/third_edition/html/interfaces.html#9.3] "Field (Constant) Declarations", [§4.12.4|http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.12.4] "final Variables", [§8.3.1.1|http://java.sun.com/docs/books/jls/third_edition/html/classes.html#8.3.1.1] static Fields"

...