GeeCON Prague 2014*
The moose likes Java in General and the fly likes imutable class Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Java » Java in General
Bookmark "imutable class" Watch "imutable class" New topic
Author

imutable class

Duray Rajesh
Greenhorn

Joined: Jun 16, 2006
Posts: 12
hi
Hw can i make a user defined class immutable
Chengwei Lee
Ranch Hand

Joined: Apr 02, 2004
Posts: 884
Make it a final class. Check out the Java API for examples, such as the String class.


SCJP 1.4 * SCWCD 1.4 * SCBCD 1.3 * SCJA 1.0 * TOGAF 8
Duray Rajesh
Greenhorn

Joined: Jun 16, 2006
Posts: 12
hi,
I have another doubt, Stringbuffer also declared as final,but we
are calling it as Mutable one,how?
Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 14194
    
  20

Just making the class final is not enough to make it immutable.

Immutable means that the state of instances of the class can't be changed after the instance is initialized. There are a number of reasons that explain why you would want that, I'm not going to explain them here.

Class java.lang.String for example is immutable - the class does not contain any methods that change the content of the string (although new users sometimes are confused about this).

To make an immutable class, you simply have to make sure that you don't provide any methods in the class that alter the state of the object after initialization.


Java Beginners FAQ - JavaRanch SCJP FAQ - The Java Tutorial - Java SE 8 API documentation
Rajah Nagur
Ranch Hand

Joined: Nov 06, 2002
Posts: 239
Originally posted by Jesper Young:

To make an immutable class, you simply have to make sure that you don't provide any methods in the class that alter the state of the object after initialization.


But cannot a class state be altered by using Reflection API?


You can't wake a person who is <b><i>pretending</i></b> to be asleep.<br />Like what <b>"it"</b> does not like - <i> Gurdjieff </i>
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24187
    
  34

Originally posted by Rajah Nagur:


But cannot a class state be altered by using Reflection API?


Yes, but this doesn't count. Reflection can be blocked by a SecurityManager, so if you need to be able to really trust that an immutable class is immutable (as when a container is hosting downloaded code, like an applet container) then the SecurityManager can enforce this.


[Jess in Action][AskingGoodQuestions]
Tony Morris
Ranch Hand

Joined: Sep 24, 2003
Posts: 1608
You create a type contract (read: interface) that declares that all operations are referentially transparent (hint: google search term). Since referential transparency generally applies to functional programming (FP), I will show you a simplified version of the translation from OO to FP.

Any OO "method" has a direct analogous function. Simply, take the type that it is declared on and add that type as the first parameter to a function.

Here is a quick (because I've said it enough times already) example:
Given String.charAt(int), the translation to a function is (very roughly):
char charAt(String, int).
This function is referentially transparent. In fact, all operations on type String can be said to be referentially transparent, therefore, we (well you might but I don't) say it is immutable. I don't use this term because of its association with informality, marketing literature and established but ill-formed beliefs.

Perhaps it's time for a detailed FAQ.


Tony Morris
Java Q&A (FAQ, Trivia)
Ken Blair
Ranch Hand

Joined: Jul 15, 2003
Posts: 1078
Originally posted by Tony Morris:
Perhaps it's time for a detailed FAQ.


Indeed. That was a very good explanation if a little thin for brevity.
Tony Morris
Ranch Hand

Joined: Sep 24, 2003
Posts: 1608
Originally posted by Tony Morris:
You create a type contract (read: interface) that declares that all operations are referentially transparent (hint: google search term). Since referential transparency generally applies to functional programming (FP), I will show you a simplified version of the translation from OO to FP.

Any OO "method" has a direct analogous function. Simply, take the type that it is declared on and add that type as the first parameter to a function.

Here is a quick (because I've said it enough times already) example:
Given String.charAt(int), the translation to a function is (very roughly):
char charAt(String, int).
This function is referentially transparent. In fact, all operations on type String can be said to be referentially transparent, therefore, we (well you might but I don't) say it is immutable. I don't use this term because of its association with informality, marketing literature and established but ill-formed beliefs.

Perhaps it's time for a detailed FAQ.


Upon rereading this, I feel compelled to add one more point, since it is very important. Going back to the statement that the function:
char charAt(String, int) is referentially transparent, we (as users of Java) know this because the API "says so". We cannot write a "unit test" for it. Here is roughly how it would look like if you attempted it:

Obviously you cannot iterate to infinity. In fact, in Java is impossible to prove referential transparency. I believe that if this were not the case, the way we approach software development with Java would be extremely different.

In contrast, functional programming languages provide mathematical proof of referential transparency. Or simply, "if it ain't referentially transparent, it won't compile".
Ken Blair
Ranch Hand

Joined: Jul 15, 2003
Posts: 1078
I would be curious how FP mathematically proves it in a way Java cannot but that's a bit off-topic.
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24187
    
  34

Originally posted by Tony Morris:
in Java is impossible to prove referential transparency.


Sorry, Tony, but that's just prejudicial twaddle.



Axioms, from the JLS:

i) a private member is accessible only by code within its class
ii) only assignment can change the value of a variable
iii) a class's code doesn't change over time

Proof:

1) By inspection, there are no assignments to x in this class
2) By (i), there can be no assignments to x from any other class
3) By 1, 2, (ii), and (iii), x will never change; it is a constant
4) x() returns a constant; it is referentially transparent (by definition).

The only hole in this proof is reflection, and if you invoke that to beat down this, than I can invoke any sort of extra-lingual memory-address-twiddling to make any Scheme function return a random number, too.

I assert that similar proofs can be constructed for any class that we would call "immutable."
Tony Morris
Ranch Hand

Joined: Sep 24, 2003
Posts: 1608

Sorry, Tony, but that's just prejudicial twaddle.

It's not actually - though I'm not compelled to prove my case given the lack of depth in the initial refutation. I have work to do...
Tony Morris
Ranch Hand

Joined: Sep 24, 2003
Posts: 1608
On second though, I retract and resort to my initial comment of the requirement of a "detailed FAQ".
 
GeeCON Prague 2014
 
subject: imutable class