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) [JLS 2013] allows implementations to insert the value of any public final field 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. This problem may occur, for example, when a third-party library is updated to the latest version but the referencing code is not recompiled.
A related error can arise when a programmer declares a
static final reference to a mutable object (see OBJ50-J. Never confuse the immutability of a reference with that of the referenced object for additional information).
Noncompliant Code Example
In this noncompliant code example, class
Foo.java 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
But if a developer were to change the value of
VERSION to 2 by modifying
Foo.java and subsequently recompile
Foo.java while failing to recompile
Bar.java, the software would incorrectly print
Bar.java solves this problem, a better solution is available.
Other than for true mathematical constants, we recommend that source code make very sparing use of class variables that are declared
final. If the read-only nature of
finalis required, a better choice is to declare a
private staticvariable and a suitable accessor method to get its value.
In this compliant solution, the version field in
Foo.java is declared private static and accessed by the
Bar class in
Bar.java is modified to invoke the
getVersion() accessor method to retrieve the
version field from
In this solution, the private version value cannot be copied into the
Bar class when it is compiled, consequently preventing the bug. Note that this transformation imposes little or no performance penalty because most just-in-time (JIT) code generators can inline the
getVersion() method at runtime.
Declaring a value that changes over the lifetime of the software as final may lead to unexpected results.
According to §9.3, "Field (Constant) Declarations," of the JLS [JLS 2013], "Every field declaration in the body of an interface is implicitly
final. It is permitted to redundantly specify any or all of these modifiers for such fields." Therefore, this guideline does not apply to fields defined in interfaces. Clearly, if the value of a field in an interface changes, every class that implements or uses the interface must be recompiled (see MSC53-J. Carefully design interfaces before releasing them for more information).
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 JLS recommends that mathematical constants be declared final.