Hi Friends... i just want to get clarify my doubts about "immutable class" String class in JDK is immutable , i think even some wrapper classes like Boolean Integer is also i am not sure about that.
How to make a my own class immutable and what is advantage that i get while coding a class as "immutable". some i when googled i came to know we have to in corporate all thses in class to make a class "immutable" class sud be final , with private fields and it sud not have seeter methods.
I just posted this because String is the "immutable" and creates a new object when ever the data is added ...
Now as end of the line 2 str is "intial text" now str in line 2 is pointing to newly created test and str in the line 1 which is pointed to "intial" is garbage collected .... and same applies to line 3....,
Since This "immutable" class is all disadvantge they SUN tried to remove it or rather re define those classes muthable one...
Since Sun kept i might think there is sort of advantage either in performance or.....
Am i going wrong... any where
author and iconoclast
The StringBuffer and StringBuilder classes are provided to efficiently assemble Strings from pieces. If Strings weren't immutable, then you could never save a String passed in as an argument into a member variable or collection without copying it first. Think of how many more copies that would represent!
As I said, "immutable" in English just means "not changeable". All this means is that the String API doesn't provide any way to change the contents of the String. The StringBuffer class, on the other hand, you can modify all you want. I think you may be overthinking this -- there's nothing more to it than that. An immutable class is one that doesn't provide any way to change the member variables of an object after it's created. A mutable class is one that does.
at last i found the answer Thanks fo spending your valuable time ....
An immutable class (String) is one that doesn't provide any way to change the member variables of an object after it's created. A mutable class (StringBuffer) is one that does. [ July 24, 2005: Message edited by: Gowtham Ganamukala ]
The distinction between mutability and immutability is typicaly made to distinguish between types that should be used locally and/or in method parameters/return types. This is usually a "more correct" design (inadvertantly following Design By Contract). i.e. passing/returning mutable types is an implicit violation of requirement (providing excessive contract).
Therefore, if you were to formalise your approach further, you'd find that you would follow other certain rules (to avoid violation of requirement): - mutability/immutability is specified on the interface (not the concrete type) - all contracts (public methods) are specified on an interface. (there are many more, but I'll omit them for brevity - the biggest single controversial one is that non-final classes imply a violation of requirement)
Unfortunately, the core API violates many of these fundamentals, and by using Java, you typically use the core API, but as it evolves, it moves more and more toward them (will someone in Sun wake up?). For example, the String class now has some of its public methods specified on an interface (java.lang.CharSequence), which specifies immutability (by definition of its API specification). In any case, even if the core API were completely rewritten properly, the language itself is tied to some of these flawed concepts.
Acknowledging the numerous flaws assists in making informed decisions. Hope this helps.