New Object Creation vs. Field Setters

Question

I know this is massively context dependent, but is there some rule of thumb to follow when it comes to deciding between
i) Making an class's fields final and creating a new object with new field values when needed, and
ii) Leaving a class's fields mutable and using setter methods to alter the field.
I tend toward option one, because not only do I tend to shy away from setters, but also because it helps prevent me from accidentally maintaining an old reference. However, purely from a performance standpoint, which option should you assume is better? How many object's of X size do I have to be making per unit of time before the performance benefits of "final" are lost?
Thanks!

Answer 1

I've been wishing for a while that Java would add a language level concept of immutability. Either an immutable keyword or an annotation. The compiler would bitch if you declared a class immutable and each of its fields was not final and either a primitive or a reference to an immutable class. Or perhaps it could simply check that there was no assignment to any field.
It would be handy for me as a user of a class to know that it's immutable, for things like copying and thread-safety. It might or might not allow for runtime optimizations too.
As for whether to make a given class immutable, like others say--it depends on the semantics of the class. If it's intended to represent something dynamic--e.g. a clock, or a piece on a board whose position changes with time, or the state of a network interface including packet sent and received--then it will make your code clunky and nonintuitive if you have to create a new object everytime the state of the thing you're modeling changes. But if it's something that changes less frequently, or that represents a fairly static entity or "value", then make it immutable.
I do agree with duffymo: Better that an object comes out of construction in a valid and useful state. So even if the object is mutable, pass field values to the c'tor or set them to reasonable defaults inside the c'tor (e.g., "now", etc.)