----- Original message ----- > On 12/19/2013 12:16 PM, Greg Trasuk wrote: <SNIP> > 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. >
In River's case, every service was constructed unsafely, period, no exceptions, in fact the likelihood of not needing it is low, yes there are alternate methods including not using final fields, but they are cumbersome and unfriendly, there be dragons and only hacker knights would dare tread. I offer thee this magic sword with which to slay your dragon. No really, it's a fine sword... But as Dan suggests, it isn't my job to stop people cutting themselves, (Dan, put those scissors down now!) so people are free not to use it and I have decided to reduce logging to FINE so you can switch it off if it annoys you. Ironically that bug you can't sort will mysterously disappear when you turn logging back on as that irritating message about safe construction confronts you. For other cases where using such an interface would have broken backward compatibility, I had to create an abstract superclass with a stateless subclass to ensure I had safe construction. See LookupDiscoveryManager and its abstract superclass in qa_refactor for an example. I had to get advice from the concurrency interest list to solve that one. You know JoinManager's private classes were synchronizing on their own object locks to access their outer classes state? Oops! You are a passionate sort with your strengths and weaknesses, like everybody, I do enjoy our conversations and could listen while you go blue in the face explaining why we should love and preserve our existing code, in all its buggy glory. Please stop now and read the code and do some research before making any more comments to preserve any credibility that remains. If you're worried about my code, you should be much more worried about the existing, can it weather the oncoming muticore cyclone (Australian for hurricane)? How many cores did you have in 2003 son? One more vote, c'mon at least one for my sense humour? Dan? No takers? Oh well... Merry Christmas, Peter. > > (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
