There is another bit missing for immutability: that class isn't declared as final. There's more about immutability in the Java™ Tutorials.
Campbell Ritchie wrote:You should make the class final, otherwise it is possible for a subclass to add a field and restore mutability.
I don't consider that to break immutability. Sure, the new properties and methods of the class may be mutable, but any code that uses references of the immutable supertype won't notice any difference at all.
I challenge you to implement MutablePerson in such a way that the program's view of immutable is altered in any way.
That might be a reference to the immutable supertype but the runtime type is mutable; you might need a cast to make Billy Bunter go to a different school, but it can be done.
Stephan van Hulst wrote:. . . any code that uses references of the immutable supertype won't notice any difference at all. . . .
Yes, it is bad design to add fields like that, and it will mess up equals() too, but it can be done.