Why are Joda objects immutable?

Question

I have read that with a Java version less than 7, Joda Time objects are more reliable than Java's built-ins. One cited reason is that Joda objects are immutable. Why is this beneficial? If I want to change the year, hour, and timezone of a Joda DateTime object, I need to make three copies!

Answer 1

If I want to change the year, hour, and timezone of a Joda DateTime object, I need to make three copies!

Yes, indeed. Or you could create one new object, using all the fields you like from the old object, of course.

This is a thoroughly good thing - because it means when you want to rely on an object not changing, it won't. Consider this pseudo-code:

private static final Instant EARLIEST_ALLOWED_ARTICLE = ...;

private Instant creationTimestamp;

public Article(Instant creationTimestamp, ...) {
    if (creationTimestamp.isBefore(EARLIEST_ALLOWED_ARTICLE)) {
        throw new IllegalArgumetnException(...);
    }
    this.creationTimestamp = creationTimestamp;
    ...
}

That's fine, because Instant is immutable. If it were mutable, the validation in the constructor would be worthless - unless you created a defensive copy at that point.

In my experience, you want to pass around references and know that the values won't change more than you want to actually make changes to existing objects, so immutability leads to fewer bugs (with mutable objects you can forget to take a copy, and any validation is then useless) and fewer copies being made.

Basically, it allows you to reason about your code locally without making copies of everything you either accept and store, or return to other code. When only your code can change the state of your object, it's much simpler to work out what will happen over time.

Joda Time actually fails somewhat because it has both mutable and immutable types - if you just program to the interface (e.g. ReadableInstant) then you don't get those guarantees. That's why in Noda Time I made all the types genuinely immutable.

Out of interest, would you want String to be mutable? If not, try to think about whether there are real differences between the two scenarios.

Answer 2

The simplest answer is that once you create an object, you know that it cannot change. This means that you won't run into a situation where your data changes in unexpected ways (in other parts of the code or different threads, perhaps).

This makes the object's behaviour more predictable and reliable.

Answer 3

There might be many reasons but one good one regards hashing. Immutable objects can be used in hashing data structures (e.g. HashSet, keys in HashMaps, etc) because their hash code and "equality" semantics will not change. Mutable objects are not suitable for hashing since mutations might change their hash code or equality.

By making Joda dates immutable they can now be used in hashing data structures.

Answer 4

I would assume that it's due to this:

Imagine you have a java.util.Date-object, that is used in multiple classes. I'm doing development on one class, you on the other. Then, I decide that I need to predict the future, but instead of creating a new Date-object, I take the one that I already have, the one you think represent a certain point in time, and I add three hours to it. Now, your code might run into serious problems at runtime. This can all be avoided using an immutable object, because you can't change its state, you can't mess it up for anyone else.