[concurrency-interest] Good terminology for setting up effectively immutable objects?

Jed Wesley-Smith jed at atlassian.com
Mon Apr 28 20:48:27 EDT 2008

I thoroughly agree. Working on a large code-base with init methods 
throughout, there is a lot to like about the guarantees that true 
immutability gives you. Firstly you ensure that your objects are 
correctly set up and all invariants are honoured. Secondly, you get 
memory visibility guarantees regarding the initial values that you need 
safe publication otherwise to achieve (well, true immutability gives you 
safe publication without extra effort). Publication errors are some of 
the most painful to diagnose and reproduce. You can also then make sure 
that any builders are stack local.

As to making builder more palatable, whenever I have pointed out all the 
problems with effective immutability and safe publication and the 
potential gotchas of getting it wrong, the builder overhead starts to 
look very attractive.


Mark Thornton wrote:
> Matthias Ernst wrote:
>> Hi,
>> often I neither want a huge (number of) constructor(s) nor want to
>> jump through hoops of using a Builder to guarantee final-ness of my
>> object's dependencies but want to rely on effective immutability
>> instead. I want to rely on my clients' common sense that anything that
>> is not documented as changeable should not be changed during use. I.e.
>> a number of setters that they may only call a) before starting to use
>> the object and b) before publishing it to other threads.
> While I have written this sort of code often enough, I can't avoid the
> feeling that I should have used the builder pattern in most of the
> cases. In fact all of them, should probably have been genuinely
> immutable and not merely effectively immutable. Can we find a way to
> make the builder pattern more palatable?
> Mark Thornton

More information about the Concurrency-interest mailing list