Note | ||
---|---|---|
| ||
This guideline has been deprecated. It has been merged with: 06/15/2015 -- Version 1.0 |
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.
Noncompliant Code Example (Mutable Class, final
Reference)
In this noncompliant code example, the programmer has declared the reference to the point
instance to be final
under the incorrect assumption that doing so prevents modification of the values of the instance fields x
and y
. The values of the instance fields can be changed after their initialization because the final
clause applies only to the reference to the point
instance and not to the referenced object
When you declare a variable final
, you do not want anyone to change it. If the type of variable is primitive types, you can undoubtedly make it final. If the variable is a reference to an object, however, what you think is final may not be.
Noncompliant Code Example
In this example, the value of a
and b
has been changed, which means that when you declare a reference final
, it only means that the reference cannot be changed, but the contents it refers to can still be changed.
Code Block | ||
---|---|---|
| ||
class Test{Point { private int x; private int y; Test Point(int ax, int by) { this.ax = ax; this.by = by; } void set_abxy(int ax, int by) { this.ax = ax; this.by = by; } void print_abxy() { System.out.println("the value ax is: " + this.ax); System.out.println("the value by is: " + this.by); } private int a; private int b; }} public class TestFinal1PointCaller { public static void main(String[] args) { final TestPoint mytestpoint = new TestPoint(1, 2); mytestpoint.print_abxy(); //now we changeChange the value of ax,b. y mytestpoint.set_abxy(5, 6); mytestpoint.print_abxy(); } } |
Noncompliant Code Example
Compliant Solution (final
Fields)
When the values of the x
and y
instance variables must remain immutable after their initialization, they should be declared final
. However, this invalidates a set_xy()
method because it can no longer change the values of x
and y
:If you do not want to change a
and b
after they are initialized, the simplest approach is to declare them final:_
Code Block | ||
---|---|---|
| ||
void set_abclass Point { private final int x; private final int y; Point(int ax, int by) { //But now compilerthis.x complains= about set_ab method! x; this.ay = a; this.b = b; } private final int a; private final int b; |
But now you cannot have setter methods of a
and b
.
Compliant Solution
y;
}
void print_xy() {
System.out.println("the value x is: " + this.x);
System.out.println("the value y is: " + this.y);
}
// set_xy(int x, int y) no longer possible
}
|
With this modification, the values of the instance variables become immutable and consequently match the programmer's intended usage model.
Compliant Solution (Provide Copy Functionality)
If the class must remain mutable, another compliant solution is to provide copy functionality. This compliant solution provides a clone()
method in the class Point
, avoiding the elimination of the setter method:An alternative approach is to provide the clone method in the class. When you want do something about the object, you can use the clone method to get a copy of an original object. Now you can do anything to this new object and the original one will never be changed.
Code Block | ||
---|---|---|
| ||
final public class NewFinalPoint implements Cloneable { private int x; private int y; Point(int x, int y) { NewFinal this.x = x; this.y = y; } void set_xy(int ax, int by) { this.ax = ax; this.by = by; } void print_abxy() { System.out.println("the value ax is: "+ this.ax); System.out.println("the value by is: "+ this.by); } void set_ab(int a, int b){ this.a = a; this.b = b; } public NewFinal } public Point clone() throws CloneNotSupportedException{ NewFinalPoint cloned = (NewFinalPoint) super.clone(); return cloned; } private int a; private int b; } // No need to clone x and y as they are primitives return cloned; } } public class Test2PointCaller { public static void main(String[] args) { throws CloneNotSupportedException final NewFinal mytest{ Point point = new NewFinalPoint(1, 2); // Is not changed in main() mytestpoint.print_abxy(); //get Get the copy of original object Point pointCopy try {= point.clone(); // pointCopy now holds a unique NewFinalreference mytest2to = mytest.clone(); the // newly cloned Point instance //now we changeChange the value of ax,by of the copy. mytest2pointCopy.set_abxy(5, 6); //but theOriginal original value will not be changedremains unchanged mytestpoint.print_abxy(); } catch (CloneNotSupportedException e) { // TODO Auto-generated catch block e.printStackTrace(); } } } |
One common mistake about this is to use public static final array. Clients will be able to modify the contents of the array (although they will not be able to change the array itself, as it is final).
Noncompliant Code Example
Wiki Markup |
---|
With this declaration, {{SOMETHINGS\[1\]}}, etc. can be modified by clients of the code. |
Code Block | ||
---|---|---|
| ||
public static final SomeType [] SOMETHINGS = { ... };
|
Compliant Solution
One approach is to make use of the above method: first define a private array and then provide a public method that returns a copy of the array:
Code Block | ||
---|---|---|
| ||
private static final SomeType [] SOMETHINGS = { ... };
public static final SomeType [] somethings() {
return SOMETHINGS.clone();
}
|
Now the original array values cannot be modified by a client.
Compliant Solution
An alternative approach is to have a private array from which a public immutable list is constructed:
Code Block | ||
---|---|---|
| ||
private static final SomeType [] THE_THINGS = { ... };
public static final List<SomeType> SOMETHINGS =
  Collections.unmodifiableList(Arrays.asList(THE_THINGS));
|
Now neither the original array values nor the public list can be modified by a client.
Risk Assessment
Using final
to declare the reference to an object is a potential security risk because the contents of the object can still be changed.
Recommendation | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
OBJ03-J | medium | likely | medium | P9 | L2 |
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
References
Chapter 6, Core Java⢠2 Volume I - Fundamentals, Seventh Edition by Cay S. Horstmann, Gary Cornell
Publisher:Prentice Hall PTR;Pub Date:August 17, 2004
}
|
The clone()
method returns a copy of the original object that reflects the state of the original object at the moment of cloning. This new object can be used without exposing the original object. Because the caller holds the only reference to the newly cloned instance, the instance fields cannot be changed without the caller's cooperation. This use of the clone()
method allows the class to remain securely mutable. (See OBJ04-J. Provide mutable classes with copy functionality to safely allow passing instances to untrusted code.)
The Point
class is declared final
to prevent subclasses from overriding the clone()
method. This enables the class to be suitably used without any inadvertent modifications of the original object.
Applicability
Incorrectly assuming that final
references cause the contents of the referenced object to remain mutable can result in an attacker modifying an object believed to be immutable.
Bibliography
Item 13, "Minimize the Accessibility of Classes and Members" | |
Chapter 6, "Interfaces and Inner Classes" | |
[JLS 2013] |
...
OBJ02-J. Avoid using finalizers 06. Objects Orientation (OBJ) OBJ31-J. Misusing public static variables