My learning curve is high enough as it is, thanks.

Sometimes I use final on production code if I know myself: remindering me not to change the input properties (next difficulty: what is the second best parameter name?!). These situations are very rare and more of the kind of syntactic sugar.

I ALWAYS use the final keyword for JUnit test-methods (have thought about it long time): Just be be sure not no override a testcase- and/or setup-method in a subclass (of a fixture).

Gordon

private int value = …

public void setValue(int value){
value = value; //oops, forgot this
}

This is a trivial example, there there are more complex examples where you accidentally assign to variable you meant to retrieve a value from.

As someone mentioned above, I think the performance gain is no longer there because the compiler is better about determining if the variable is mutated or not and doing the appropriate optimizations if it isn’t.

I look at it sort of like Override– most of the time it doesn’t matter, but the time you leave it out will be the time you spend two hours trying to figure out why your method isn’t being called because you put the wrong generified type on it… say, like this morning.

Sometimes I mark method parameters in the case where some are being modified and some are not to indicate which are the “input” and which are the “inout” or “output”.

However, I believe it’s highly worth marking object fields as final and I strive to accurately label immutability there and hopefully to mark everything as immutable if possible.

I do use “final” quite a bit on fields, though. It’s good to know which fields are mutable state and which aren’t. Also, I’m not at all shy about making final fields public rather than create getters for them.