Meaningless Drivel is fun!
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Question on immutability Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Question on immutability" Watch "Question on immutability" New topic

Question on immutability

Anuradha Prasanna
Ranch Hand

Joined: Mar 09, 2006
Posts: 115
We all know,

Strings are immutable.

Can anyone explain how to make a immutable class?

SCJP 6.0 90%
Muhammad Khojaye
Ranch Hand

Joined: Apr 12, 2009
Posts: 449

Anuradha Prasanna wrote:
Can anyone explain how to make a immutable class?

I got this link on first page when google.
Prithvi Sehgal
Ranch Hand

Joined: Oct 13, 2009
Posts: 774
Hello Anu,

In order to amke the class immutable we must restrict changing the state of the class object by any means. This means
avoiding an assignment to a variable. We can achieve this through a final modifier. To further restrict the access we can use a private access modifier.
Above do not provide any method where we modify the instance variables.

But one problem is that, what if someone creates a sub class from this immutable class? The new subclass can contain methods, which override our base
class(immutable class) method. From this class we can change the variable values.

So one approach is to make the methods final in the class or more better approach, make the immutable class itself final. So there is no overriding only.
For example, String is an immutable class and it's final.

Hope this helps,

My Blog, Follow me on Twitter,Scjp Tips, When you score low in mocks, Generics,Scjp Notes, JavaStudyGroup
Anuradha Prasanna
Ranch Hand

Joined: Mar 09, 2006
Posts: 115
Prithvi ,

By the way you explained,

A state of the class should not be changed if it has to be immutable.

For example,

public class Immutable {

private String name = "java";
private String id = "203";

public String getName() { return name; }
public String getId() { return id; }


is the above class immutable?
Larry Olson
Ranch Hand

Joined: Feb 03, 2009
Posts: 142
Your Immutable class example seems to be immutable to me (even though the class isn't declared final).

Even if someone tries to extend the class, there isn't much they could do to change the immutable property of the class. I would be curious to know if someone thinks otherwise and why.

But I suppose there is much more to immutable Strings than what is shown in this particular example. You can set the String specific values and everytime you do this a new String is being created and the original String still remains in the String pool. You could have to give it some careful thought to design a class like that.
Paul Clapham

Joined: Oct 14, 2005
Posts: 19973

Larry Olson wrote:Your Immutable class example seems to be immutable to me (even though the class isn't declared final).

Yes, it is. Except as you say for omitting to declare it final. Consider this:

Which is clearly mutable. But so what? you might say. That's a subclass. How does it affect the immutability of the superclass? Well, consider this:

There you have an object of Immutable type (it's a subclass, but that doesn't matter). And you called a method -- getName -- which modified the state of the object. The output of the two print statements will demonstrate that by being different.
Charles Owen
Ranch Hand

Joined: Aug 31, 2009
Posts: 61
According to a Java tutorial, these conditions must be met in order for an object to be immutable:

1. Don't provide "setter" methods — methods that modify fields or objects referred to by fields.
2. Make all fields final and private.
3. Don't allow subclasses to override methods. The simplest way to do this is to declare the class as final. A more sophisticated approach is to make the constructor private and construct instances in factory methods.
4. If the instance fields include references to mutable objects, don't allow those objects to be changed:
* Don't provide methods that modify the mutable objects.
* Don't share references to the mutable objects. Never store references to external, mutable objects passed to the constructor; if necessary, create copies, and store references to the copies. Similarly, create copies of your internal mutable objects when necessary to avoid returning the originals in your methods.
I agree. Here's the link:
subject: Question on immutability
It's not a secret anymore!