# String concet

Printable View

• 12-20-2011, 08:20 AM
sangramkeshari.jena
String concet
Hi,
What is the difference between
String s="abc";
s="def";
AND
int i=5;
i=9;
Means s is reassign to "def" and i is reassing to 9.Is it break the Immutabe concept.

Please explain the concept.

Regards,
Sangram
• 12-20-2011, 09:30 AM
pbrockway2
Re: String concet
Code:

```String s = "abc"; s = "def"; int i = 5; i = 9; Point p = new Point(3, 4); // the thing referenced by p has coordinates (3,4) p = new Point(5, 12); // a new, different, thing referenced by p has coordinates (5,12) p.move(3, 4); // p has not changed value but the thing referenced by p now has coordinates (3,4)```
s is assigned one value and then assigned a different value. i is assigned a value and then assigned a different value. In an important sense there is no difference. Same with p (ignore the last line)

Unless they are declared "final" all variables can be assigned a new value. When people talk about "immutability" they are not usually talking about whether a variable can change value.

-----

Variables "stand for" or "represent" things (integers, strings, points). The values of primitive variables (like i) *are* the things they stand for. The values of reference variables (like s or p) are references to the things they stand for.

Immutability isn't about the variables, it's about the things they stand for.

Take the case of "int i = 5". It doesn't matter if i changes value, 5 will always be 5. In particular whatever we do to it (like add 3) we will always get the same answer. There is a sense in which 5 is immutable (unchanging).

The variables of reference type are more interesting. Take the case of "p = new Point(5,12)". If we say p.distance(0.0,0.0) we get the distance to the origin (13), but we we move() p as in the last line and do the same operation we get 5. So the operation "get the distance to the origin" does *not* always yield the same answer. p has not changed value, but the thing it stands for has changed "state". Instances of Point are said to be "mutable" in the sense that they can change state in this way.

Not all the things that reference variables stand for are mutable. It turns out that strings are also immutable - a string will always and forever be the same sequence of characters. There is no method like move() that will change its state. A Point instance may be a different distance from the origin at different times, but a String instance will never have a different length for instance.

-----

Often when people use the term "mutable" and "immutable" they are referring to the things that references stand for and not to primitive values. (I've described 5 as immutable above because it resembles a String instance rather than a Point instance. Sorta/Kinda. But primitives don't have methods, so you may consider the matter moot.) I don't think there is a clear cut "definition", especially in Java where there is no way of marking variables or the things they stand for as "mutable" or "immutable" and hence the terms do not form any part of the definition of the language.

-----

Executive summary (of little value beyond enabling you to tick the right box in a multichoice test):

final vs not == variables cannot or can change value
immutable vs mutable == objects cannot or can change state
• 12-20-2011, 04:00 PM
JosAH
Re: String concet
I like the analogy where the reference variable is the remote control and the object itself is the television set. There's a nice article about it on Java Ranch, but I can't find the link, sorry about that.

kind regards,

Jos
• 12-21-2011, 07:14 AM
sangramkeshari.jena
Re: String concet
Thanks..

Quote:

Originally Posted by pbrockway2
Code:

```String s = "abc"; s = "def"; int i = 5; i = 9; Point p = new Point(3, 4); // the thing referenced by p has coordinates (3,4) p = new Point(5, 12); // a new, different, thing referenced by p has coordinates (5,12) p.move(3, 4); // p has not changed value but the thing referenced by p now has coordinates (3,4)```
s is assigned one value and then assigned a different value. i is assigned a value and then assigned a different value. In an important sense there is no difference. Same with p (ignore the last line)

Unless they are declared "final" all variables can be assigned a new value. When people talk about "immutability" they are not usually talking about whether a variable can change value.

-----

Variables "stand for" or "represent" things (integers, strings, points). The values of primitive variables (like i) *are* the things they stand for. The values of reference variables (like s or p) are references to the things they stand for.

Immutability isn't about the variables, it's about the things they stand for.

Take the case of "int i = 5". It doesn't matter if i changes value, 5 will always be 5. In particular whatever we do to it (like add 3) we will always get the same answer. There is a sense in which 5 is immutable (unchanging).

The variables of reference type are more interesting. Take the case of "p = new Point(5,12)". If we say p.distance(0.0,0.0) we get the distance to the origin (13), but we we move() p as in the last line and do the same operation we get 5. So the operation "get the distance to the origin" does *not* always yield the same answer. p has not changed value, but the thing it stands for has changed "state". Instances of Point are said to be "mutable" in the sense that they can change state in this way.

Not all the things that reference variables stand for are mutable. It turns out that strings are also immutable - a string will always and forever be the same sequence of characters. There is no method like move() that will change its state. A Point instance may be a different distance from the origin at different times, but a String instance will never have a different length for instance.

-----

Often when people use the term "mutable" and "immutable" they are referring to the things that references stand for and not to primitive values. (I've described 5 as immutable above because it resembles a String instance rather than a Point instance. Sorta/Kinda. But primitives don't have methods, so you may consider the matter moot.) I don't think there is a clear cut "definition", especially in Java where there is no way of marking variables or the things they stand for as "mutable" or "immutable" and hence the terms do not form any part of the definition of the language.

-----

Executive summary (of little value beyond enabling you to tick the right box in a multichoice test):

final vs not == variables cannot or can change value
immutable vs mutable == objects cannot or can change state

• 12-21-2011, 08:53 AM
pbrockway2
Re: String concet
You're welcome.