public final class ImmutableClass {

    private StringBuffer name;

    public ImmutableClass(StringBuffer name) {
    public StringBuffer getName() {
        return name;

Points that I have considered:

  1. Make the class final so that it cannot be extended
  2. Do not provide public mutator methods
  3. Keep the instance variables private

Are the above mentioned considerations sufficient?

  • 8
    The StringBuffer can be modified after you pass it as an argument to your class, it can also be modified after you return it with getName() so no, it's not immutable. BTW StringBuffer shouldn't be used and StringBuilder replaced it nearly ten years ago. Commented Dec 6, 2013 at 8:24
  • 1
    Check this also: @Immutable
    – yegor256
    Commented Dec 6, 2013 at 16:47

2 Answers 2



ImmutableClass a = new ImmutableClass(new StringBuffer("hello"));
a.getName().append(" world");
System.out.println(a.getName()); // prints "hello world"

The above allows the caller to mutate the value of name. Or:

StringBuffer b = new StringBuffer("hello");
ImmutableClass a = new ImmutableClass(b);
System.out.println(a.getName()); // prints "hello"
b.append(" world");
System.out.println(a.getName()); // prints "hello world"

The above is similar, and shows that a change to something else can affect the apparent value of a.

With the ability to do the above, your class cannot be considered "immutable" by any definition. However, if you were to replace StringBuffer with String, then your class would be immutable (because in Java, String is immutable).

  • I got your point. Does it mean that members of the class have to be immutable themselves(if they can be accessed in some way like in my example) to achieve overall immutability for the class?
    – Nishant
    Commented Dec 6, 2013 at 4:59
  • 1
    @n1234: Basically, yes. Immutability must include all the parts a user can see and touch by any means. If you wanted to clone the StringBuilder, you could do that and still consider the type immutable...but the one you're holding must never be accessible to the outside world (because it's mutable, and you can't keep it from being so).
    – cHao
    Commented Dec 6, 2013 at 5:45
  • 2
    even with String inside, one would need final modifier in field declaration private final String name; to guarantee immutability in multithreaded context, see eg About reference to object before object's constructor is finished. Consider editing your (otherwise very good) answer to account for that
    – gnat
    Commented Dec 6, 2013 at 6:10
  • Came to comment about same thing - even the field should have the final modifier. All the fields should have. This will ensure that you won't modify it accidentally. If you do, the compiler will complain. This also means, every time a field changes, you should create a totally new object, thus immutable.
    – Sundeep
    Commented Dec 6, 2013 at 6:36
  • 1
    @Sundeep I mean that if you never set the value outside the constructor or if you use lazy instantiation (where you can't use final) then it can be considered immutable as long as the user never sees it change. As for thread safety: check gnat's link: final enforces some volatile-like semantics (reads always seeing the value it was set to) Commented Dec 6, 2013 at 11:03

Whether the class is immutable or not depends upon whether you are intending it to encapsulate the identity of the StringBuffer or the contents thereof. The design of the class suggests that it encapsulates the identity of the StringBuffer; because it will never identify any StringBuffer other than the instance identified to it at instantiation, the class ImmutableClass may be regarded as immutable. Nonetheless, instances of ImmutableClass which encapsulate a particular StringBuffer should not be exposed to any code which cannot be trusted with an unguarded reference to that StringBuffer.

The pattern of having an immutable class identify a mutable object is not very common, but there are a few cases where it may be appropriate. Perhaps the most natural example would be a class whose purpose is to set a mutable object to some particular state; such a class would encapsulate a reference to the object in question along with the desired state. If the identity of the object and the state to which it should be set are both immutable, than the class encapsulating those things would likewise be immutable. A key aspect of such designs is that the class which encapsulates the identity of the mutable object doesn't care regard the state of that object as being parts of its own state. That situation is very different from a type which holds a reference to an unshared mutable object for the purpose of encapsulating its own state therein. An object which encapsulates mutable state anywhere, whether in itself or in another object, is mutable. Merely holding a reference to a mutable object, however, does not imply encapsulating state thereof.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.