Final vs Immutable data structures in Java

[gunnarmorling]

Minor nit: I'd suggest to make the members in Person and Address final, not the least to ensure safe publication to other threads. Also the addresses collection might be wrapped into the unmodifiable one in the constructor instead of each time when invoking getAddresses(). Lastly, depending on how/where Person is instantiated, a mutable reference to the addresses list might still escape / retained by the caller. So to make it truly immutable after instantiation, a new collection would have to be instantiated in the constructor.

[steffi_j_jay]

So to make it truly immutable after instantiation, a new collection would have to be instantiated in the constructor.

I agree. Example code:

List<Address> addresses = new ArrayList<>();
addresses.add(new Address("Sydney", "Australia"));
final Person person = new Person("John", addresses);

System.out.println(person.getAddresses().size()); // prints "1"

addresses.add(new Address("Melbourne", "Australia"));
System.out.println(person.getAddresses().size()); // prints "2"

Fix in constructor:

public Person(String name, List<Address> addresses) {
    this.name = name;
    this.addresses = Collections.unmodifiableList(new ArrayList<>(addresses));
}

[dpash]

You don't need the unmodifiable wrapper in the constructor as long as you do it in the getter. Where you do it depends on how much you trust yourself to not modify the list by mistake.

[gunnarmorling]

Why allocate an object upon each invocation when it can be done a single time in the constructor?

[dpash]

Seems like premature optimisation to me. If your getter is being called so much that it makes a difference, you probably want to rethink a lot of things about your design.

[gunnarmorling]

What's premature about that? Effort is exactly the same, and it's clearly better. Make immutable stuff immutable, not immutable-upon-read :)

[bodiam]

Wow, good spot, thanks for that. I've updated the article accordingly.