An immutable class is simply a class whose instances cannot be modified. All of the information contained in each instance is provided when it is created and is fixed for the lifetime of the object.
Source: Immutable

Description

When designing a new information holding class, we need to consider whether it should be mutable (changeable) or immutable (not changeable), or maybe a little bit of both. Each approach has some pitfalls but we can overrcome such problmes by a careful design process.
A powerful and simple concept in programming that is really underused: Immutability.
An object is immutable if its state doesn’t change once the object has been created. Consequently, a class is immutable if its instances are immutable. The Immutable pattern increases the robustness of object that share references to the same object & reduces the overhead of concurrent access to an object.

Purpose

Why are immutable objects, so good then? There are many reasons for sure, here are the three main ones
Protection
We can send an immutable object to any class without worrying about it being altered by that class, and we never have to make a defensive copy. Same when we get one for local storage in your class (for instance a cache), we don't have to worry about whether the provider will hold on to a reference and change it later, invalidating our cache without our knowledge.
Performance
As we don't have to make defensive copies all the time. This means that we save some work on the garbage collector which intern increases performance and decreases memory overhead, and we all want that don't we?
Thread Safe
After creation any number of threads can access them simultaneously, without any synchronization.

Pros

  • Since the state of immutable objects never changes, there is no need to write code to manage such changes.
  • Instances of the immutable class are unique which means that tests for matches can be made using the == operator instead of the more expensive equals() method.
  • Immutable objects are simple.
  • Immutable objects are inherently thread-safe; they require no synchronization.
  • Immutable objects can be shared freely.
  • Not only can you share immutable objects, but you can share their internals.
  • Immutable objects make great building blocks for other objects.
  • The best use of the immutable objects is as the keys of a map.

Consequences

  • It may cause memory growth (it's not a leak if it's an intentional behavior). Whether it will or won't depends on just how the uniqueness contract is specified.
  • Your program uses instance of a class that is passive in nature.
  • An immutable object is often used as the value of another object's attribute.
  • Operation that would have change the state of an object must create a new object.
    • Coordinating changes to the contents of a value object used by multiple objects can be a source of bugs. When the contents of a value object change, all the object that use it may need to be informed.
    • When multiple objects use an object, they may attempt to change its state in inconsistent ways.
    • Multiple threads can modify the contents of a value object, the modification operation must be synchronized to ensure the consistency of the contents.
    • Synchronized the threads may add unacceptable overhead to accessing the value object's contents.
    • Alternative to modifying the contents of a value object is to replace the entire object object with another object that has different contents. Doing so avoid the need for synchronization among threads that only fetch the contents of the value object.
    • Multiple threads that update the content of an object, replacing the object instead of updating its content will not avoid the need for synchronizing threads that do the updating.
    • If the changes to an object is frequent, or object has large amount of state information associated with it, the cost of replacing the value objects may be prohibitive.
  • The only real disadvantage of immutable classes is that they require a separate object for each distinct value.

Immutable Pattern in Java

  • All wrapper classes in java.lang are immutable – String, Integer, Boolean, Character, Byte, Short, Long, Float, Double, BigDecimal, BigInteger.
  • The class java.awt.Rectangle encapsulates the position and dimension of a rectangle.
  • java.lang.StackTraceElement (used in building exception stacktraces)
  • Most enum classes are immutable, but this in fact depends on the concrete case. (Don't implement mutable enums, this will screw) I think that at least all enum classes in the standard API are in fact immutable.
  • java.math.BigInteger and java.math.BigDecimal
  • java.io.File. Note that this represents an object external to the VM (a file on the local system), which may or may not exist, and has some methods modifying and querying the state of this external object. But the File object itself stays immutable.
    All other classes in java.io are mutable.
  • java.util.Locale - representing a specific geographical, political, or cultural region.

Immutable Pattern in Java

  • Don’t provide any methods that modify the object’s state (No method, other then constructor should modify the values of class's instance variables)
  • Ensure that the class can’t be extended (Generally accomplished by making the class final to avoid sub classing)
  • Make all fields private and final (This prevents clients from obtaining access to mutable objects referred to by fields and modifying these objects directly)
  • Ensure exclusive access to any mutable components (If a class has any fields that refer to mutable objects, ensure that clients of the class cannot obtain references to these objects)
  • Any method that computes new state information must store the information in a new instance of the same class rather then modifying the existing object's state.
Implementation

Related pattern

Read-only interface pattern
Read-only interface pattern is an alternative to the Immutable object pattern. It allows some objects to modify a value object while other objects can only fetch its values.

References

  • http://stackoverflow.com
  • http://www.javalobby.org
  • Patterns in Java by Mark Grand
  • Effective Java 2nd Edition by Joshua Bloch