On 12/19/2013 12:16 PM, Greg Trasuk wrote:
+0. Let me explain… Having a separate interface to say start() is all very well and harmless in itself, but: (a) It doesn’t really address the issue of how service instances
should be started. We don’t actually have solid recommendations on this issue, although there have been attempts in various containers to systematize it.
(b) the proposed warning addresses a case where a service instance is
doing “exporter.export(this);”, which I’d call bad practice in any case. It happens that ServiceStarter appears to encourage this use case because it works by calling a constructor. But the called constructor could (and should) construct an instance of some other class, and then export and register that instance rather than “this”. That style doesn’t mandate a Startable interface, and having Startable doesn’t mandate good multi-threaded code. In other words, you could implement Startable and still have poor thread-safety. And, using, for example, the strategy you describe of constructing another object, code can be perfectly valid without using Startable. I see value in offering the interface, and a rule that the start method will be called after the constructor for any service implementing it. I don't think River should assume code is not safe just because it does not use that feature - it may be safe for entirely different reasons.
(c) even where there is an apparent problem, the exposure window is
very small. Remember an exposure window can be small in terms of numbers of statements, but long in terms of elapsed time. Leaving apparently small windows open can result in code that fails mysteriously, for example when a page boundary happens to fall in the window, and the system is under memory pressure. Patricia
