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.

Your second point in beans is not in favour of beans, but in favour of the Builder pattern. You can still construct an immutable object.
– user23743Oct 26 '10 at 20:42

3

You don't mention threading with the immutable POJOs, which is by far one of the biggest reasons to use them. Another important item is simplicity - when an object doesn't change, it's easier to work with in the long run. Also, with immutable POJOs, you don't need to worry about cloning the object in general, you can just pass it around.
– deterbOct 28 '11 at 18:12

Well it depends on what you're trying to do. If your working with a persistent layer, and you fetch some row from the database into a POJO, and you want to change a property and save it back, using JavaBean style would be better, especially if you have a lot of properties.

Consider that your person, has a lot of fields like, first, middle, last name, date of birth, family members, education, job, salary etc.

And that Person happens to be a female that just got married and accepted to have her last name changed, and you need to update the database.

If you're using immutable POJO, you fetch a Person object representing her, then you create a new Person object to which you pass all the properties that you didn't change as they are, and the new last name, and save it.

If it were a Java bean you can just do setLastName() and save it.

It's 'Minimize mutability' not 'never use mutable objects'. Some situations work better with mutable objects, it's really your job to decide if making an object mutable will better fit your program or not. You shouldn't always say 'must use immutable objects', instead see how many classes you can make immutable before you start hurting yourself.

But your example is almost never what needs to be done in "real" applications. Usually your updated data object needs to be passed to a validation framework (Hibernate Validator, Spring Validator, etc) where the object is subjected to various operations possibly written by different developers. If the object is mutable, you don't know if you are working with the same data that was passed in (if some validation executed prior to yours mutated the object in place). It makes the validation process less determinant, more dependent on strict order, and unparallelizable.
– dsmithSep 20 '16 at 20:24

In addition, a "real" application will probably have some sort of in-memory or distributed cache (EHCache, etc) that contain your domain objects. If you know your objects are immutable, you don't need to incur the overhead of copy-on-read. You can safely retrieve and use the in-memory object without worrying about cache integrity. IMHO, for business domain objects of this sort, you always want immutable objects. Mutable objects are OK for local scope and a few other specialized cases that I don't have the characters to get into here.
– dsmithSep 20 '16 at 20:46

Inmutability facilitates correctness (structs can be passed by reference and you know nothing will be destroyed by a faulty/malicious client) and code simplicity

Mutability facilitates homogeneity: Spring and other frameworks create an object with no arguments, set object properties, and voi là. Also make interfaces easier using the same class for giving data and saving modifications (you don't need get(id): Client and save(MutableClient), being MutableClient some descendant of Client.

If there were an intermediate point (create, set properties, make inmutable) maybe frameworks would encourage more an inmutable approach.

Anyway I suggest thinking in inmutable objects as "read only Java Beans" stressing the point that if you are a good boy and don't touch that dangerous setProperty method all will be fine.

I would agree that the best of both worlds would be for libraries and frameworks to move to a immutable approach. The advantages of immutable are intrinsic, whereas the advantages of mutable are incidental.
– dsmithSep 20 '16 at 19:32

I don't think immutable objects will get all that popular, to be honest.

I do see the advantages, but frameworks like Hibernate and Spring are currently very much in vogue (and for a good reason too), and they really work best with beans.

So I don't think immutability is bad, but it would certainly limit your integration options with current frameworks.

EDIT The comments prompt me to clarify my answer a bit.

There most certainly are problem areas where immutability is very useful, and is indeed used. But I think the current default seems to be mutable as that is what is mostly expected, and only immutable if that has a clear advantage.

And though it is indeed possible to use constructors with arguments in Spring it seems to be intended as a way to use legacy and/or third party code with you beautiful brand-new Spring code. At least that's what I picked up from the documentation.

The idea of IoC/DI is based on setting/injecting state, this is why immutability is not so popular in Spring. However Joda-Time is a good example of immutability done right.
– lunohodovAug 18 '10 at 10:47

You can use constructor args to inject dependencies with spring as well, it just seems that not many people do that (possibly because when you have a lot of dependencies, having a 10+ parameter constructor is scary).
– Andrei FierbinteanuAug 18 '10 at 10:52

6

@lunohodov: I have used Google Guice for DI/IoC and there is no problem to do dependency injection to the constructor.
– JonasAug 18 '10 at 10:55

In general, it's easiest to work with things (especially in a multi-threaded environment) if data is stored using immutable-once-created references to mutable objects or mutable references to immutable objects. Having freely-mutable references to mutable objects makes things more complicated. Note that if X and Y refer to the same object and one wants to change X.something, one may keep the identity of X and change Y.something, or leave Y.something unchanged and change the identity of X, but one cannot keep the identity of X and the state of Y while changing the state of X.
– supercatDec 6 '13 at 18:34

Those who push the use immutable objects sometimes fail to recognize the importance of object identity, and the fact that mutable objects can have an immutable identity in a way that immutable objects cannot.
– supercatDec 6 '13 at 18:37