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

Matthias Ernst matthias at mernst.org
Wed Apr 30 09:08:47 EDT 2008


I understand the concern. I just don't see adding this code overhead
to my code. I think that safe publication and happens-before are
wonderful abstractions, good to reason about and I'm so glad we have
them. I believe this should be the canonical style. Unsafe publication
should be forbidden except for the few core cases that required having
it in the first place.

And that leads to what's bugging me (never quite having been able to
phrase it) about your and similar arguments that came up in
discussions about safety of servlet initialization and DI containers:
I know it's defensive engineering but at the same time it's positive
reinforcement for unsafe publication practices. It appears to shifts
responsibility from the client and makes components even more
expensive to write. I would like to take an absolute stance - client
code doing unsafe publication is buggy and must be fixed. I'm not
willing to go out of my way in order to safeguard against other
people's bugs.

Having said that, I love final fields and I've been dreaming about a
way to have _clients_ initialize blank final fields. Something like:

X x = new X() {{
 foo = bar;
}};

where foo is a blank final unassigned in the X() constructor. But
haven't thought that through.

So anyone that does have a name for requiring setters to be only
called during the "setup phase"?

Cheers
Matthias

On Tue, Apr 29, 2008 at 2:48 AM, Jed Wesley-Smith <jed at atlassian.com> wrote:
> 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.
>
>  cheers,
>  jed.
>
>
>
>  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
>  >
>
>  _______________________________________________
>  Concurrency-interest mailing list
>  Concurrency-interest at altair.cs.oswego.edu
>  http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>


More information about the Concurrency-interest mailing list