java - Why final keyword is necessary for immutable class?

Question

Could you please clarify that why final keyword is required before class when we are making it an immutable one. I mean, if we declare all of it's attributes as private and final, then also it is an immutable class, isn't it?

Sorry if the question seems easy, but i am truly confused about it. Help me out.

Editted: I know that a class declared final can't be subclassed.. But if each attribute is private and final then what difference does that make?

Answer 1

As stacker says, final makes sure the class isn't subclassed. That's important so that any code which is relying on its immutability can do so safely.

For example, immutable types (where each field is also of an immutable type) can be freely used between threads without worrying about data races etc. Now consider:

public class Person {
    private final String name;

    public Person(String name) {
        this.name = name;
    }

    public String getName() {
        return name;
    }
}

That looks like you can share Person instances freely across threads with no problem. But what about when the object you're sharing is actually a mutable subclass:

public class Employee extends Person {
    private String company;

    public Employee(String name, String company) {
        super(name);
        this.company = company;
    }

    public void setCompany(String company) {
        this.company = company;
    }

    public String getCompany() {
        return company; 
    }
}

Now instances of Employee aren't safe to share between threads, because they're not immutable. But the code doing the sharing may only know about them as instances of Person... leading them into a false sense of security.

The same goes for caching - it should be safe to cache and reuse immutable types, right? Well, it is safe to cache instances which are genuinely of an immutable type - but if you're dealing with a type which itself doesn't allow mutation, but does allow subclasses, it's suddenly not safe any more.

Think about java.lang.Object. It doesn't have any mutable fields, but it's clearly a bad idea to treat every Object reference as if it's a reference to an immutable type. Basically it depends on whether you think about immutability as a property of the type or of objects. A truly immutable type declares "any time you see a reference of this type, you can treat it as immutable" - whereas a type which allows arbitrary subclassing can't make that claim.

As an aside, there's a half-way house: if you can limit the subclassing to only "trusted" places, you can ensure that everything's immutable, but still allow that subclassing. The access in Java makes that tricky, but in C# for example you could have a public class which only allowed subclassing within the same assembly - giving a public API which is nice and strong in terms of immutability, while still allowing for the benefits of polymorphism.