| Note | ||
|---|---|---|
| ||
This guideline has been deprecated. It has been merged with: 06/15/2015 -- Version 1.0 |
Immutability helps to support security reasoning. It is safe to share immutable objects without risk that the recipient can modify them [Mettler 2010].
Programmers often incorrectly assume that declaring a field or variable final makes the referenced object immutable. Declaring variables that have a primitive type to be final does prevent changes to their values after initialization (by normal Java processing). However, when the variable has a reference type, the presence of a final clause in the declaration only makes the reference itself immutable. The final clause has no effect on the referenced object. Consequently, the fields of the referenced object may be mutable. For example, according to the Java Language Specification, §4.12.4, "final Variables" [JLS 2013],
If a
finalvariable 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 applies also to arrays because arrays are objects; if a final variable holds a reference to an array, then the components of the array may still be changed by operations on the array, but the variable will always refer to the same array.
Similarly, a final method parameter obtains an immutable copy of the object reference. Again, this has no effect on the mutability of the referenced data.
...
Item 13, "Minimize the Accessibility of Classes and Members" | |||
Chapter 6, "Interfaces and Inner Classes" | |||
[JLS 2013] | Class Properties for Security Review in an Object-Capability Subset of Java |
...