This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
I am facing one easy question and I want your help. I am trying to understand immutable objects and I have read that Strings belongs to that category, meaning that their values cannot be changed after they are created. What this mean? I have create the following code and it's change fine:
When we say immutable, we mean the object cannot be changed. For instance, if I have the below code
Now we have created a String object with the value "Bacon is delicious". When we try to add " and nutritious!" to that object....well, we can't. Strings are immutable. So Java actually creates a whole new object, with the value "Bacon is delicious and nutritious!" and assigns it to test. The original String object containing "Bacon is delicious" still exists, we just don't have a variable pointing to it.*
*There was also a String object " and nutritious!" created, but String creation is a little off-topic.
When I die, I want people to look at me and say "Yeah, he might have been crazy, but that was one zarkin frood that knew where his towel was."
Immutable means you can't change the values of the object. For instance, if you have an object with a field that you can modify either directly or through some method, then that object is called mutable.
However, if you have an object that never changes once its created, it's called immutable. String is such a class. Once you've created a String (remember that you create an instance of a String when you use a String literal), you can never change the value of that String.
Just take a String reference, and try calling any of its methods. You won't be able to change anything about the variable.
The mind is a strange and wonderful thing. I'm not sure that it will ever be able to figure itself out, everything else, maybe. From the atom to the universe, everything, except itself.
Keep in mind that 's' is just a variable that references an object. The variable is not the object itself.
The first object that 's' references is a String, "defaultValue." This object is immutable. It will always be "defaultValue."
But you can reassign the variable to point to another object. "newValue" is an entirely different String object (also immutable). When you assign 's' to point to this second String, the first String object, "defaultValue" remains unchanged. It's simply no longer referenced by 's'.
"We're kind of on the level of crossword puzzle writers... And no one ever goes to them and gives them an award." ~Joe Strummer sscce.org
In my example when I reassign the String variable to 'newValue' a new reference value was created with the old value existing but without any reference to it.
So I have to be careful when creating immutable objects because of leaving them unused in the memory until garbage collector runs.
naro pad wrote:...In my example when I reassign the String variable to 'newValue' a new reference value was created with the old value existing but without any reference to it...
You got it!
naro pad wrote:... So I have to be careful when creating immutable objects because of leaving them unused in the memory until garbage collector runs...
Well, that's a more complex issue that goes beyond immutable objects (and is further complicated by the String pool). But you have the right idea, because unreferenced objects will contine to exist in memory until collected.
an object is like a house, and a variable is like a note card with the address of the house written down on it.
String s = "defaultValue";
creates a String object with a value of 'defaultValue'. it creates a String reference called 's' that has the address of the object written down on it.
s = "newValue";
creates a new String object with a value of 'newValue'. The old address stored in 's' is erased, and the new address is written on it. The old object with 'defauleValue' still exists somewhere. You simply don't have the address anymore so you can't find it.
There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors