I was more thinking along the lines of encouraging best practise. Right now, if you read River's service implementations, every single one uses final fields and publishes partially constructed service reference to other threads, the hotspot compiller is free to reorder so these, so threads see partially constructed objects and default values for final fields.
The reference shared during export is never updated, so threads carrying method invocations from remote clients never see a safely published reference and there is no way to obtain one at present. If people want it enforced, I could create a private class, that extends SecurityManager, walks the call stack, checks if export is being performed during construction, then use reflection to check for final fields and throw an exception if it does, but that doesn't ensure the service is thread safe. Presently we expect service implementations to be thread safe (remote method invocation is performed via a thread pool), but River doesn't provide an easy way for implementors to use final fields. Services can also use static methods and writeReplace, provided they're not using the starter kit. Peter. ----- Original message ----- > > 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
