Why would I want to declare a field as final when creating an immutable class without setter

Question

I am currently reading here that in order to achieve immutability of my object, I have to:

1. Declare all my fields private and final
2. Not define setters

Why do I need to declare the fields final if there are no setters anyways. The java compiler doesn't allow something like this:

myObj.getSomething() = new Somthing()

If I try to use reflection, then the final keyword doesn't stop me from changing the reference.

I found a very nice explanation here why the entire class needs to be final but nothing about why the private fields need to be final.

Edit: As a reply to GotoFinal's comment Here is a class that shows how I can edit the field with reflection:

public class Test {
static class Immutable {
    private final StringBuilder immutableField = new StringBuilder("You can't set final field just by normal reflections");

    public StringBuilder getStringBuilder() {
        return immutableField;
    }
}

public static void main(String[] args) throws Exception {
    Immutable immutableObject = new Immutable();
    Field f1 = immutableObject.getClass().getDeclaredField("immutableField");
    f1.setAccessible(true);
    f1.set(immutableObject, new StringBuilder("Well, I just did"));
    System.out.println(immutableObject.getStringBuilder());
}

}

Answer 1

It does not need to be final, but it is a good practice as when reading source code you instantly know that given field can't change - including inside of class or by local classes - declared inside your class (java will generate special bridge setter for that field then).
Also because field is final you need to initialize it inside constructor - so it is harder to make some error here.

It might also affects how deserializers will work, as most of libraries do not try to modify final fields.

Answer 2

To prevent the fields from being reassigned, you should make them final.

The strategy of just not defining setters is not enough, since:

• Other developers might add a setter because a field does not express the desire to be immutable
• Subclasses may define setters and modify the field this way

Declaring the fields as final prevents both of these. Also, it is much easier to check for a final keyword then read the entire class to verify that a setter is absent.

Furthermore, the JVM can apply various optimizations if the field declared as final. I would say reflection is irrelevant here, as anything can be bypassed using it.

Answer 3

One of the main advantages of immutable classes is that they are inherently thread-safe: if they have no mutable state, there is no way that one thread can affect the behaviour of an instance of that class seen by another thread.

Declaring a field final actually has consequences for the visibility of that field (in the sense of the Java Memory Model, not public/private). A field which is declared final is guaranteed by specification to be initialized before the constructor finishes executing.

What this means is that - provided you don't unsafely publish a reference to the instance prior to the constructor finishing - all threads are guaranteed to see the initialized value of a final field of an instance.

Without the final, there is no such guarantee this means that the instance isn't truly immutable - a thread might read one value from the instance on one occasion, and then a different value from the instance on another.