What's the difference of an object being final and an object being immutable in java?

Question

final String str = "do not change me";
str = "why not?"; //it will result in compile time error saying that final fields can not be re-assigned once created i.e. the reference cannot be changed

String str1 = "hello world";  
    System.out.println(str1.replaceAll("h", "q"));
    str1 = str1.replaceAll("h", "q");
    System.out.println(str1);  //An immutable object on the other hand means that, there is no way for you to change the object or its contents other than changing the reference.

Is the above understanding of definition of a final object and immutable object correct?

Answer 1

In Java, objects are not final. Instead: variables, classes, or methods are. A final variable cannot be reassigned, so the variable becomes interchangeable with the value it represents. This is roughly known as “referential transparency”.

An immutable object is an object without changing state. Simplified: If all member fields of an object are final variables, then it's quite likely that the object is immutable as well. If we need an object with changed state, then we have to return a new instance. This is what str.replace(…) does, because Strings are immutable in Java.

Answer 2

Objects can be immutable and references to them can be final; but the reverse is mostly technical confusion. A "final object" is really a final reference to an object, while an "immutable reference" (or "immutable field" or "immutable variable") is rarely mentioned because it is not how they are considered. A reference is effectively an address, and therefore like a primitive number or boolean. A variable or field can contain the integer 10. If you increment that integer, are you "mutating" that 10, or are you really assigning a different integer? On the bit level, you are changing the contents of a single memory location, but at the semantic language level it is the latter, since everywhere else that uses 10 is unchanged.

A final field or variable must be assigned exactly once, and the compiler will enforce this. An immutable object does not change once it has completed construction, but there is no real enforcement. Note that even if you define an object that has only final fields, that does not automatically make the object immutable. If a final field is an object reference, that nested object must be immutable. There is also no way at the language level to make an array immutable; a final reference to an array means you cannot change which array or its length, but you can change its contents. The language cannot enforce making such an object immutable. So in many cases, an object is immutable only because you intend it to be (and if there's a bug in your code, maybe it isn't).

String objects are like that: they have a final array of characters, and are immutable only because the methods that might change something return other instances instead. Methods like substring can actually share the original character array and simply "see" a different section of that array.