Take the 2-minute tour ×

I read Effective Java, and there written

If a class cannot be made immutable, limit its mutability as much as possible...


...make every field final unless there is a compelling reason to make it nonfinal.

So need I always make all my POJO(for example simple Bookclass with ID, Title and Author fields) classes immutable? And when I want to change state of my object(for example user change it in table where represented many Books), instead of setters use method like this:

public Book changeAuthor(String author) {
   return new Book(this.id, this.title, author);  //Book constructor is private

But I thing is really not good idea..

Please, explain me when to make class immutable.

share|improve this question
What is the question? –  Mark Jul 29 '12 at 10:41

3 Answers 3

up vote 5 down vote accepted

No, you don't need always to make your POJO immutable. Like you said, sometimes it can be a bad idea. If you object has attributes that will change over the time, a setter is the most comfortable way to do it.

But you should consider to make your object immutable. It will help you to find errors, to program more clearly and to deal with concurrency.

But I think you quoting say everything:




That's what you should do. Unless it's not possible, because you have a setter. But then be aware of concurrency.

share|improve this answer
+1 Sometimes a field has to be mutable or immutable, when it can be either, try to make it immutable. e.g. make fields final when you can. –  Peter Lawrey Jul 29 '12 at 10:50

1. A POJO is one which has private Instance Variables with Getter and Setter methods.

2. And Classes like String class, which needs a constant behavior/implementation at all time needs to be final, not the one which needs to change with time.

3. For making a class immutable, final is not only the solution, One can have private Instance variables, with only Getter methods. And their state being set into the Constructor.

4. Now depending on your coding decision, try to rectify which fields needs to be constant throughout the program, if you feel that certain fields are to be immutable, make them final.

5. JVM uses a mechanism called Constant folding for pre-calculating the constant values.

share|improve this answer
I think you're conflating POJO with Bean. A POJO doesn't necessarily have Getters and Setters. A Bean may or may not be a POJO, a POJO may or may not be a Bean. Source: en.wikipedia.org/wiki/Plain_Old_Java_Object –  Grundlefleck Jul 29 '12 at 14:00
@Grundlefleck well i reviewed the link you have mentioned, and i found this.. The definition of the POJO can be as follows: public class MyBean { private String someProperty; public String getSomeProperty() { return someProperty; } public void setSomeProperty(String someProperty) { this.someProperty = someProperty; } } So its the private variable with getter and setter, fine...from javaranch.com i found this Java Bean and POJO are more or less same. POJO are Plain Old Java Objects, also known as entity class. Java Beans are again the same only –  Kumar Vivek Mitra Jul 29 '12 at 14:08
That is in the context describing an example of a specific type of POJO, a Bean. The definition a POJO is a Java object not bound by any restriction other than those forced by the Java Language Specification is probably most concise and accurate. For me, at least, that would include structural restrictions (public methods prefixed with {get|set}) as restricted to by the Bean spec. –  Grundlefleck Jul 29 '12 at 14:17
Java doesnt force you to use one of the Encapsulation funda of private var, and getter/setter... its just the proper way to do it.. Now, as you said its specific type Pojo, but still its a pojo..... –  Kumar Vivek Mitra Jul 29 '12 at 14:21
that's fine, a Bean can be a POJO. but I don't agree it's correct that a POJO must have private instance variables with Getters and Setters. –  Grundlefleck Jul 29 '12 at 14:56

In OOP world we have state. State it's all properties in your object. Return new object when you change state of your object guaranties that your application will work correctly in concurrent environment without specific things (synchronized, locks, atomics, etc.). But you always create new object.

Imagine that your object contains 100 properties, or to be real some collection with 100 elements. To follow the idea of immutability you need copy this collection as well. It's great memory overhead, perhaps it handled by GC. In most situation it's better to manually handle state of object than make object immutable. In some hard cases better to return copy if concurrent problems very hard. It depends on task. No silver bullet.

share|improve this answer

Your Answer


