Why Immutable Objects Matter in Java and Object‑Oriented Design

In object‑oriented programming, an object whose state cannot change after creation is called immutable. Java’s String class is a classic example: once a String instance is created, its state cannot be altered, although new String objects can be created.

Most JDK classes are mutable; for instance, Date provides setTime() to modify its state. The author questions why similar classes are designed differently and argues that mutable objects like Date have many drawbacks, while immutable String better reflects the essence of OOP.

In a purely object‑oriented world, all classes should be immutable, though JVM constraints sometimes make this difficult. Nevertheless, developers should strive for immutability whenever possible.

Immutable objects are easier to construct, test, and use.

They are inherently thread‑safe.

They reduce coupling.

They have no side‑effects (no defensive copies needed).

State‑change bugs are avoided.

Failures are atomic.

They are easier to cache.

They eliminate null‑reference problems.

Thread Safety

The most important feature of immutable objects is thread safety: multiple threads can access the same instance simultaneously without risking conflicts, because no method can modify the object's state.

Goetz et al. discuss these advantages in detail in their well‑known book Java Concurrency in Practice .

Avoid Temporal Coupling

An example shows two consecutive HTTP POST requests where the second call depends on the first. Because the request object is mutable, the programmer must remember the call order, creating hidden temporal coupling.

If the request object were immutable, the two calls would be independent, eliminating the need to remember ordering and making the code more maintainable.

Avoid Side Effects

When a mutable request object is used in a new method, side effects can arise. By making the request immutable, the code becomes safe and free of side effects.

Avoid Identity Mutability

Objects with identical internal state are considered equal. For mutable objects like Date, changing the state also changes the object's identity, which can break collections such as HashMap when the hash code changes.

Immutable objects keep their identity stable, preventing lost map entries and hard‑to‑debug bugs.

Atomic Failure

A simple stack example shows that if an exception occurs during a push operation, the stack can become inconsistent (size increased but element not added). Because immutable objects can only change state during construction, either the construction succeeds and the object is fully valid, or it fails and no partially built object exists.

For more details, see Joshua Bloch’s Effective Java, 2nd Edition .

Arguments Against Immutability

Some claim immutability is unsuitable for enterprise projects, but many real‑world libraries (e.g., jcabi‑http, jcabi‑xml, jcabi‑github, jcabi‑s3, jcabi‑dynamo, jcabi‑simpledb) and web applications (netbout.com, stateful.co) successfully use immutable Java objects.

It is argued that updating an existing object is cheaper than creating a new one; however, Oracle notes that object‑creation costs are often overestimated and that immutability can reduce overall overhead through easier garbage collection and fewer defensive‑coding requirements.

Original source: javacodegeeks (translated by ImportNew – Liu Jiacai).