If a method has a local variable i
:
int i = 10;
and then I assign a new value:
i = 11;
Will this allocate a new memory location? Or just replace the original value?
Does this mean that primitives are immutable?
If a method has a local variable i
:
int i = 10;
and then I assign a new value:
i = 11;
Will this allocate a new memory location? Or just replace the original value?
Does this mean that primitives are immutable?
Primitive literals and
final
primitive variables are immutable. Notfinal
primitive variables are mutable.Identity of any primitive variable is the name of that variable and it's obvious that such an identity is unchangeable.
Java does not really make any guarantees that variables will correspond to memory locations; for example, your method might be optimized in such a way that
i
is stored in a register — or might not even be stored at all, if the compiler can see that you never actually use its value, or if it can trace through the code and use the appropriate values directly.But setting that aside . . . if we take the abstraction here to be that a local variable denotes a memory location on the call stack, then
i = 11
will simply modify the value at that memory location. It will not need to use a new memory location, because the variablei
was the only thing referring to the old location.Yes and no: yes, primitives are immutable, but no, that's not because of the above.
When we say that something is mutable, we mean that it can be mutated: changed while still having the same identity. For example, when you grow out your hair, you are mutating yourself: you're still you, but one of your attributes is different.
In the case of primitives, all of their attributes are fully determined by their identity;
1
always means1
, no matter what, and1 + 1
is always2
. You can't change that.If a given
int
variable has the value1
, you can change it to have the value2
instead, but that's a total change of identity: it no longer has the same value it had before. That's like changingme
to point to someone else instead of to me: it doesn't actually change me, it just changesme
.With objects, of course, you can often do both:
In common parlance, both of these will be described as "changing
sb
", because people will use "sb
" both to refer the variable (which contains a reference) and to the object that it refers to (when it refers to one). This sort of looseness is fine, as long as you remember the distinction when it matters.This isn't a full answer, but it is a way to prove the immutability of primitive-type values.
If primitive values (literals) are mutable, then the following code would work fine:
Of course, this isn't true.
The integer values, such as 5, 10 and 11 are already stored in the memory. When you set a variable equal to one of them: it changes the value in the memory-slot where
i
is.You can see this here through the bytecode for the following code:
Bytecode:
As you can see in the bytecode (hopefully) it references the literal value (example: 10) and then stores it in the slot for variable
i
. When you change the value ofi
, you are just changing which value is stored in that slot. The values themselves aren't changing, the location of them is.Immutable
means that each time the value of and object has changed a new reference is created for it on stack. You can't talk about immutability in case of primitive types,only the Wrapper Classes are immutable. Java usescopy_by_value
not by reference.It makes no difference if you're passing primitive or reference variables, you are always passing a copy of the bits in the variable. So for a primitive variable, you're passing a copy of the bits representing the value and if you're passing an object reference variable, you're passing a copy of the bits representing the reference to an object.
For example, if you pass an int variable with the value of 3, you're passing a copy of the bits representing 3.
Once a primitive has been declared,
its primitive type can never change
, although its value can change.Yes, they are immutable. They're totally unchangeable.
There's a nice explanation buried in here. It's for Go, but it's the same thing in Java. Or any other language in the C family.