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.