what is the point of having an instance variable as final?
isn´t it better to have that variable set as a static final variable then?
cause if it can't be changed by any of the objects, then it's the same as a class (static) variable, right?
+1
A:
It prevents other programmers from doing stupid things that they shouldn't try doing anyway...
Ignacio Vazquez-Abrams
2010-01-13 04:10:15
+7
A:
Nope. static means it's the same across all instances of the class. final means it's not assignable after its initial assignment. So two instances could have different values for a non-static final variable.
There are many reasons you might want to make a variable final; one of the best is clarity. If I read a method and notice that the foo is final, I don't have to worry about where it's changing down below - because it isn't; it can't. I can make more changes to code with final variables with less concern ("did I change the value of foo before or after bar, and does it matter?") because I know that some variables aren't subject to change. It also focuses my attention on the variables that are subject to change - and they're the ones that deserve more attention.
Carl Manaster
2010-01-13 04:10:52
but don´t you assign a value to the final instance variable when you write the class? then that means that all objects will use that value and they can´t change? or am i wrong?
weng
2010-01-13 04:14:10
Not necessarily - it can be assigned in the constructor.
danben
2010-01-13 04:15:45
+1
A:
You can assign it a value that is specific to the object instance, which you can't do with a static class variable.
Roy Tang
2010-01-13 04:11:01
so you mean when i write the class i just declare it as final. and when i have instantiated the class and call a method, the method will assign a value to it which cannot be changed?
weng
2010-01-13 04:16:02
I think you need to assign a value in the constructor, otherwise the compiler will throw an error.
Roy Tang
2010-01-13 05:28:38
+2
A:
That's for JVM optimizations. If all fields are final, then JVM knows the object's state can't be changed, and thus it can make many optimizations, e.g. ommiting thread safety checks etc.
From the class design view, it allows a programmer to rely on the fact that the field will not change since instantiation, thus various pre-computations can also be done.
Ondra Žižka
2010-01-13 04:11:03
@Ondra - the fact that the JVM *might* (or might not) optimize `final` fields, etc is a side-issue. The primary motivation for using `final` should be to make your code more robust. (And remember the advice that it is a bad idea to micro-optimize Java because the JIT compiler can do a better job if you don't!)
Stephen C
2010-01-13 05:15:22
@Stephen:1) I covered the "robust" aspect of final in the second paragraph. 2) Making your small data objects immutable is definitely not a microoptimization - it can provide significant performance boosts."One of the most common reasons given for not making a class immutable is the belief that doing so would compromise performance. While this is true sometimes, it is often not -- and sometimes the use of immutable objects has significant, and perhaps surprising, performance advantages."
Ondra Žižka
2010-01-13 05:55:16
+2
A:
I guess you are thinking about simple case such as:
private final int num = 3;
That can be better written as:
private static final int NUM = 3;
However, often you will have references to objects that are mutable, and therefore cannot be shared between classes:
private final List<Node> children = new ArrayList<Children>();
Or perhaps, a value passed into or derived in the constructors:
public final class MyThing {
private final String name;
public MyThing(String name) {
this.name = name;
}
[...]
}
Note: final fields can be assigned in constructors (or instance initialiser), not just as part of the declaration.
Tom Hawtin - tackline
2010-01-13 04:19:17
Your last example shows a `final` class. That has nothing to do with mutability, and is only going to confuse the novice reader.
Stephen C
2010-01-13 05:08:37