wood burning stoves 2.0*
The moose likes Java in General and the fly likes how can we make class Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCM Java EE 6 Enterprise Architect Exam Guide this week in the OCMJEA forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "how can we make class "immuatble" explicitly" Watch "how can we make class "immuatble" explicitly" New topic
Author

how can we make class "immuatble" explicitly

Ganesh Gowtham
Ranch Hand

Joined: Mar 30, 2005
Posts: 225

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.

then is the immutable class then, ??


Thanks, Ganesh Gowtham
http://ganesh.gowtham.googlepages.com
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24183
    
  34

That is an immutable class, but of course not a very useful class!

"Immutable" just means "not changeable." An object of an immutable class represents a constant of some kind, simple or complex; once initialized, it doesn't change what it represents. That's all.

In any case, I think your checklist is reasonable, although I'd generalize "no setters" to "no code that changes the user-visible state."


[Jess in Action][AskingGoodQuestions]
Ganesh Gowtham
Ranch Hand

Joined: Mar 30, 2005
Posts: 225

I just posted this because String is the "immutable" and creates a new object when ever the data is added ...

like


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
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24183
    
  34

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!
Ganesh Gowtham
Ranch Hand

Joined: Mar 30, 2005
Posts: 225

Hi Ernest ,

ok . In short what makes "String" "StrngBuffer" "immutable" and "muttable" coding..Pls let me know...
Since i cant able to get U in prev Message
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24183
    
  34

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.
Ganesh Gowtham
Ranch Hand

Joined: Mar 30, 2005
Posts: 225

Hi Friend ....

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 ]
Tony Morris
Ranch Hand

Joined: Sep 24, 2003
Posts: 1608
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.


Tony Morris
Java Q&A (FAQ, Trivia)
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
 
subject: how can we make class "immuatble" explicitly