(Java) Is Integer Immutable?

Immutable does not mean that a can never equal another value. For example String is immutable too, but I can still do this.

Immutable does not mean that a can never equal another value. For example, String is immutable too, but I can still do this: String str = "hello"; str = str + "world"; // now a == "helloworld" So what happened there? Since String is immutable, clearly str was not changed.

But it now equals something different. This is because str is now a completely newly instantiated object, just as your Integer is. So the value of a did not mutate, per se, but it was replaced with a completely new object, i.e.

New Integer(6).

This is because str is now a completely newly instantiated object". Or, rather, str (a varibale) points to a new object. The object itself is not mutable, but since the variable isn't final, it can point to a different object.

– Sandman Apr 6 at 7:20 Yes, it points to a different object that was instantiated as a result of the += operation. – Travis Webb Apr 6 at 12:20.

A is a "reference" to some Integer(3), your shorthand a+=b really means do this: a = new Integer(3 + 3) So no, Integers are not mutable, but the variables that point to them are.

You can determine that the object has changed using System. IdentityHashCode() (A better way is to use plain == however its not as obvious that the reference rather than the value has changed) Integer a = 3; System.out. Println("before a +=3; a="+a+" id="+Integer.

ToHexString(System. IdentityHashCode(a))); a += 3; System.out. Println("after a +=3; a="+a+" id="+Integer.

ToHexString(System. IdentityHashCode(a))); prints before a +=3; a=3 id=70f9f9d8 after a +=3; a=6 id=2b820dda You can see the underlying "id" of the object a refers to has changed.

Immutable does not mean that you cannot change value for a variable. It just means that any new assignment creates a new object ( assigns it a new memory location) and then the value gets assigned to it. To understand this for yourself, perform Integer assignment in a loop ( with integer declared outside the loop ) and look at the live objects in memory.

The reason why copy constructor is not needed for immutable objects is simple common sense. Since each assignment creates a new object, the language technically creates a copy already, so you do not have to create another copy.

Yes Integer is immutable. A is a reference which points to an object. When you run a += 3, that reassigns A to reference a new Integer object, with a different value.

You never modified the original object, rather you pointed the reference to a different object. Read about the difference between objects and references here.

Immutable classes do not need copy constructors". Anyone care to explain why? The reason is that there is rarely any need to copy (or even any point in copying) an instance of a immutable class.

The copy of the object should be "the same as" the original, and if it is the same, there should be no need to create it. There are some underlying assumptions though: It assumes that your application does not place any meaning on the object identity of instances of the class. It assumes that the class has overloaded equals and hashCode so that a copy of an instance would be "the same as" the original ... according to these methods.

Either or both of those assumptions could be false, and that might warrant the addition of a copy constructor.