1. Member
Join Date
Feb 2011
Posts
5
Rep Power
0

## 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.

Regards,
Sangram

2. Moderator
Join Date
Feb 2009
Location
New Zealand
Posts
4,712
Rep Power
14

## Re: String concet

Java 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
Last edited by pbrockway2; 12-20-2011 at 10:10 AM. Reason: little typo in code

3. ## 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

4. Member
Join Date
Feb 2011
Posts
5
Rep Power
0

## Re: String concet

Thanks..

Originally Posted by pbrockway2
Java 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

5. Moderator
Join Date
Feb 2009
Location
New Zealand
Posts
4,712
Rep Power
14

## Re: String concet

You're welcome.

#### Posting Permissions

• You may not post new threads
• You may not post replies
• You may not post attachments
• You may not edit your posts
•