Why make defensive copies in getters inside immutable classes?

Question

This question is about good programming practices and avoiding potential holes.
I read Joshua Bloch's Effective Java and here is what I wonder:
Why should I consider making defensive copies in getter methods in my immutable class with no mutators in it?
And second: why should I make my fields final in addition to private ? Is this only about performance (not security) ?

Answer 1

I believe this is the case that justifies this statements:

public class Immutable {

    private final String name;

    private Date dateOfBirth;

    public Immutable(String name, Date dateOfBirth) {
        this.name = name;
        this.dateOfBirth = dateOfBirth;
    }

    public String getName() {
        return name;
    }

    public Date getDateOfBirth() {
        return dateOfBirth;
    }

}

getName() is fine as it returns immutable object as well. However the getDateOfBirth() method can break immutability because the client code can modify returned object, hence modifying the Immutable object as well:

Immutable imm = new Immutable("John", new Date());

imm.getName(); //safe
Date dateOfBirth = imm.getDateOfBirth();
//hundreds of lines later
dateOfBirth.setTime(0);  //we just modified `imm` object

It is safe to return immutable objects and primitives (as they are returned by value). However you need to make defensive copies of mutable objects, like Date:

public Date getDateOfBirth() {
    return new Date(dateOfBirth.getTime());
}

and wrap collections in immutable views (if they are mutable), e.g. see Collections.unmodifiableList():

public List<Integer> getSomeIds() {
    return Collections.unmodifiableList(someIds);
}

Answer 2

Object references in Java are promiscuous; if an object reference is passed to a method, that method will have no way of knowing who else might have a reference to that same object, or likewise what they might try to do with it. Likewise if a method returns an object reference, there's no telling what the recipient might do with it. Consequently, if a type allows anyone with a reference to mutate it, the only way an entity which holds a reference to such an object can ensure it won't be mutated is to keep a reference to a private object, which outside has never had, and will never get, a reference to.

An alternative to the style of defensive copying shown here (constructing a new object instance every time information is requested) is to have an object's information-retrieval method accept a mutable object and populate that object with the information that is retrieved. This approach requires that the code which is asking for the information construct a (likely blank) object to accept the information before calling the method to retrieve it, but if one will e.g. use a loop to retrieve, examine briefly, and discard 100 pieces of information, it may be faster to construct one object which can be reused every time through the loop, than to construct 100 new objects each of which will be used only briefly.