ImmutableClass | An immutable class container for C | Continuous Deployment library

Your immutable class is like a titanium and concrete monument. Once created it is pretty much inpervious to vandalism.

Written on your monument is the location on the beach of a very pretty sand castle.

One person expects their full enjoyment of your monument to include finding that, driving over there, and gazing at the sand castle.

A second person drives over there and flattens the castle out.

The first person now feels their experience was changed.

A third person decides to hold a philosophical debate on what immutable means, and says that the monument has not changed at all: That location of the sand castle is still there, unchanged.

The first and third person decide to have a fist fight about it.

You tell me, who is right? The first, or the third?

Because it is an exact match to what's happening in your java code. You're like the first guy. Whomever said that 'make a class final, and every field final, and then the objects of that class will be immutable' is like the third.

If you want the monument's experience to not change, then either that sand castle needs to also be a titanium-and-concrete concept, which is not something the builders of this monument can do (you'd have to ask the builders of the sand castle to do this), or you need to not put the locations of non-impervious things on that monument.

In other words, either don't include fields of non-immutable types in your class if you want it to be 'experience' immutable - i.e. don't have fields of type ComplexObj, or alternatively, make those immutable too, i.e. edit ComplexObj.java and e.g. make that field final.