On Jan 22, 2014, at 657AM, Peter <j...@zeus.net.au> wrote: > Startable only had one purpose: > > To provide the implementor a thread of execution after construction completes. > > It's provided by the the infrastructure to the service implementation, what > the implementor does with it is their business.
By itself it's harmless, but the point being here is that the Startable interface semantics cannot enforce the problem you are trying to solve. > > One alternative was, for our service implementations to be moved to abstract > classes and threads started and exporting performed in stateless concrete > classes, the other was to removal all final field modifiers, Startable was > simple and seemed more elegant. > > That's about it in a nutshell, sorry if you got the impression it had another > purpose. > > The problem with the tests; they've had bug fixes too, so people have trouble > trusting them. > > The section of code you've found in Outrigger is ugly but correct, ideally > sync would be the responsibility of resource but in this case it's external. Synchronizing on local variables is usually a bad idea. If the object that resource points to will *always* be the same, then the synchronized(resource) block does in fact use that quasi-global object's monitor. IMO it would be a better practice to use a synchronized wrapper here. Dennis
