The final
keyword can be used to specify constant values (that is, values that cannot change during program execution). However, constants that can change over the lifetime of a program should not be declared public final. The Java Language Specification [JLS 2011] allows implementations to insert the values of public final fields inline in any compilation unit that reads the field. Consequently, if the declaring class is edited so that the new version gives a different value for the field, compilation units that read the public final field could still see the old value until they are recompiled.
A related error can arise when a programmer declares a static final
reference to a mutable object; see OBJ50-J. Never 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
:
Code Block | ||
---|---|---|
| ||
class Foo { public static final int VERSION = 1; // ... } |
Bar.java
:
Code Block | ||
---|---|---|
| ||
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
Code Block |
---|
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:
Code Block |
---|
You are using version 1 |
Although recompiling Bar.java
solves this problem, a better solution is available.
Compliant Solution
According to §13.4.9, "final
Fields and Constants" of the Java Language Specification [JLS 2011],
Other than for true mathematical constants, we recommend that source code make very sparing use of class variables that are declared
static
andfinal
. If the read-only nature offinal
is required, a better choice is to declare aprivate static
variable and a suitable accessor method to get its value.
Consequently, a compliant solution is:
Foo.java
:
Code Block | ||
---|---|---|
| ||
class Foo { private static int version = 1; public static final String getVersion() { return version; } // ... } |
Bar.java
:
Code Block | ||
---|---|---|
| ||
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.
Applicability
Declaring as final
a value that changes over the lifetime of the software may lead to unexpected results.
According to §9.3, "Field (Constant) Declarations" of the Java Language Specification [JLS 2011], "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."
Constants declared using the enum
type are permitted to violate this guideline.
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
.
Bibliography
[JLS 2011] | |
| |
| |
|