Why shouldn't I use immutable POJOs instead of JavaBeans?

I have implemented a few Java applications now, only desktop applications so far. I prefer to use immutable objects for passing the data around in the application instead of using objects with mutators (setters and getters), also called JavaBeans.

But in the Java world, it seems to be much more common to use JavaBeans, and I can't understand why I should use them instead. Personally the code looks better if it only deals with immutable objects instead of mutate the state all the time.

Immutable objects are also recommended in Item 15: Minimize mutability, Effective Java 2ed.

If I have an object Person implemented as a JavaBean it would look like:

public class Person {
    private String name;
    private Place birthPlace;

    public Person() {}

    public setName(String name) {
        this.name = name;
    }

    public setBirthPlace(Place birthPlace) {
        this.birthPlace = birthPlace;
    }

    public String getName() {
        return name;
    }

    public Place getBirthPlace() {
        return birthPlace;
    }
}

And the same Person implemented as an immutable object:

public class Person {
    private final String name;
    private final Place birthPlace;

    public Person(String name, Place birthPlace) {
        this.name = name;
        this.birthPlace = birthPlace;
    }

    public String getName() {
        return name;
    }

    public Place getBirthPlace() {
        return birthPlace;
    }
}

Or closer to an struct in C:

public class Person {
    public final String name;
    public final Place birthPlace;

    public Person(String name, Place birthPlace) {
        this.name = name;
        this.birthPlace = birthPlace;
    }
}

I could also have getters in the immutable object to hide the implementation details. But since I only use it as a struct I prefer to skip the "getters", and keep it simple.

Simply, I don't understand why it's better to use JavaBeans, or if I can and should keep going with my immutable POJOs?

Many of the Java libraries seem to have better support for JavaBeans, but maybe more support for immutable POJOs gets more popular over time?

Solution 1:

Prefer JavaBeans When

• you have to interact with environments that expect them
• you have lots of properties for which it would be inconvenient to do all initialization on instantiation
• you have state that is expensive or impossible to copy for some reason but requires mutation
• you think at some point you may have to change how properties are accessed (e.g. moving from stored to calculated values, access authorization, etc.)
• you want to conform to coding standards that mindlessly insist it is somehow more "object-oriented" to use JavaBeans

Prefer Immutable POJOs When

• you have a small number of simple properties
• you do not have to interact with environments assuming JavaBean conventions
• it is easy (or at the very least possible) to copy state when cloning your object
• you don't ever plan on cloning the object at all
• you're pretty sure that you don't ever have to modify how properties are accessed as above
• you don't mind listening to whining (or sneering) about how your code isn't sufficiently "object-oriented"

Solution 2:

I was surprised that the word Thread did not appear anywhere in this discussion.

One of the main benefits of immutable classes is that they are inherently more thread safe due to no mutable, shared state.

Not only does this make your coding easier, it'll also give you two performance benefits as a side effect:

• Less need for synchronization.

• More scope for using final variables, which can facilitate subsequent compiler optimisations.

I am really trying to move towards immutable objects rather than JavaBean style classes. Exposing the guts of objects via getters and setters should probably not be the default choice.