Page History

Invariants cannot be enforced for public nonfinal fields or for final fields that reference a mutable object. A protected member of an exported (non-final) class represents a public commitment to an implementation detail. Attackers can manipulate such fields to violate class invariants, or they may be corrupted by multiple threads accessing them concurrently [Bloch 2008]. As a result, fields must be declared private or package-private.

...

Programmers often incorrectly assume that declaring a field or variable final makes the referenced object immutable. Declaring variables that have a primitive type final does prevent changes to their values after initialization (by normal Java processing). However, when the field has a reference type, declaring the field final only makes the reference itself immutable. The final clause has no effect on the referenced object. According to The Java Language Specification, §4.12.4, "final Variables" [JLS 20132015],

If a final variable holds a reference to an object, then the state of the object may be changed by operations on the object, but the variable will always refer to the same object.

...

This compliant solution declares a public private array and provides public methods to get individual items and array size:

...

Because a copy of the array is returned, the original array values (the references to the String objects) cannot be modified by a client. Note that a manual deep copy could be required when dealing with arrays of objects. This generally happens when the objects do not export a clone() method (see OBJ06-J. Defensively copy mutable inputs and mutable internal components for more information).

As before, this method provides direct access to the array objects themselves, but this is safe because String is immutable. If the array contained mutable objects, the getItems() method could should return an array of cloned objects instead.

...

This compliant solution constructs a public immutable list from the private array. It is safe to share immutable objects without risk that the recipient can modify them [Mettler 2010]. This example is safe because String is immutable.

private static final String[] items = { ... };

public static final List<String> itemsList =
  Collections.unmodifiableList(Arrays.asList(items));

Neither the original array values nor the public list can be modified by a client. For more details about unmodifiable wrappers, refer to OBJ56-J. Provide sensitive mutable classes with unmodifiable wrappers. This solution can also be used when the array contains mutable objects.

Exceptions

OBJ01-J-EX0: Fields with no associated behavior or invariants can be public. According to Sun's Code Conventions document [Conventions 2009]:

One example of appropriate public instance variables is the case where the class is essentially a data structure, with no behavior. In other words, if you would have used a struct instead of a class (if Java supported struct), then it's appropriate to make the class's instance variables public.

OBJ01-J-EX1: Fields in a package-private class or in a private nested class may be pubic or protected. There is nothing inherently wrong with declaring fields to be public or protected in these cases. Eliminating accessor methods generally improves the readability of the code both in the class definition and in the client [Bloch 2008].

OBJ01-J-EX2: Static final fields that contain or reference immutable constants may be public or protected.

...

Failing to limit field accessibility can defeat encapsulation, allow attackers to manipulate fields to violate class invariants, or allow these fields to be corrupted as the result of concurrent accesses from multiple threads.

Automated Detection

Detection of public and protected fields is trivial; heuristic detection of the presence or absence of accessor methods is straightforward. However, simply reporting all detected cases without suppressing those cases covered by the exceptions to this rule would produce excessive false positives. Sound detection and application of the exceptions to this rule is infeasible; however, heuristic techniques may be useful.

Related Guidelines

Bibliography

...

OBJ00-J. Limit the extensibility of classes and methods with invariants Image Added