Use of synchronized methods in components

[Rod Widdowson]

> One of those "I keep forgetting to mention it" things. I noticed that a
> lot of the older components I've done work on used the synchronized
> keyword on the setters, but that's not universally true (and I know I've
> created some that don't follow that).

Me too.  I never managed to remember since in the cases I have seen the
contention is going to be non-existent and mostly one-off at config time.
My feeling is that this dates from very early on in the design when Chad
hadn't sorted out how asynchrony was going to work.  So I reckoned it was
harmless, but of course it does give the impression that there is some sort
of different synchronization going on and so there is harm (plus of course
cpu cycles).

The most egregious example is the setId on the AbstractIndentified
component.
 
> My opinion is that the Initializable metaphor is/was basically a
> substitute for implicit synchronization in the code, it's a contract
> essentially that the objects won't be mutated after initializing them,
> guarded by the "throw if initialized" checks in the setters.

Exactly.

Are we suggesting that this be removed as and when we see it, or as a
conscious effort?

I would also add that I have never understood what the @Threadsafe means
when applied to a class.  I am not a neophyte with asynchronous systems, but
I cannot really understand what it is meant to indicate - or rather I can
think of too many thinks that it could mean.  Do we believe that this adds
any value and of not can it go?

R