Are all primitive wrapper classes immutable objects?

Question

Are all primitive wrapper classes in Java immutable objects? String is immutable. What are the other immutable objects?

Answer 1

Before Java 5, all the primitive wrapper classes were immutable.

However, the atomic wrapper classes introduced in Java 5 (AtomicInteger, AtomicLong, AtomicBoolean and AtomicReference<V>) are mutable.

Answer 2

Yes, of course. Wrapper classes are immutable.

You can read Why wrapper classes are immutable in java? to understand the immutability of wrapper classes.

Answer 3

One odd "wrapper" class is Void which doesn't have any valid objects, immutable or otherwise. It can only be set to null.

One use for Void is to mark generic return types with no value. (You can't use primtive types or void)

e.g.

Callable<Void> callable = new Callable<Void>() {
    public Void call() {
         // do something
        return null;
    }
};

---

Even though Date is technically mutable, I would describe it as "immutable by convension". It is generally understood or assumed you wouldn't change a Date object but would replace it to change it like any other immutable object.

Answer 4

Any type which doesn't give you any means to change the data within it is immutable - it's as simple as that. Yes, all the primitive wrapper types are immutable¹, as is String. UUID, URL and URI are other examples.

Although Calendar and Date in the built-in Java API are mutable, many of the types within Joda Time are immutable - and to my mind, this is one reason why Joda Time is easier to work with. If an object is immutable, you can keep a reference to it somewhere else in your code and not have to worry about whether or not some other piece of code is going to make changes - it's easier to reason about your code.

---

¹ by which I mean java.lang.Integer etc. As noted elsewhere, the Atomic* classes are mutable, and indeed have to be in order to serve their purpose. There's a difference in my mind between "the standard set of primitive wrapper classes" and "the set of classes which wrap primitive values".

You can write your own mutable wrapper class very easily:

public class MutableInteger
{
    private int value;

    public MutableInteger(int value) 
    {
         this.value = value;
    }

    public int getValue()
    {
        return value;
    }

    public void setValue(int value)
    {
        this.value = value;
    }
}

So as you can see, there's nothing inherently immutable about wrapper classes - it's just that the standard ones were designed to be immutable, by virtue of not providing any way to change the wrapped value.

Note that this allows for the same object to be used repeatedly when boxing, for common values:

Integer x = 100;
Integer y = 100;
// x and y are actually guaranteed to refer to the same object

Integer a = 1000;
Integer b = 1000;
// a and b *could* refer to the same object, but probably won't