I might raise some eyebrows here, but why does the design preference go to creating new classes and not, in some of the cases, to providing new attributes in an existing class with getters/setters that the programmer can change when desired, like setSynchronized(boolean i)?
Or should I go back and read an OO book?
Gian Franco Casula [ August 25, 2004: Message edited by: Gian Franco Casula ]
[Herb]: Since I could only offer conjectures, I must remain silent regarding your question.
C'mon, Herb, the rest of us don't let that stop us.
My thinking is that StringBuffer has a clear API in this regard: " The methods are synchronized where necessary so that all the operations on any particular instance behave as if they occur in some serial order that is consistent with the order of the method calls made by each of the individual threads involved.". It doesn't say "unless you call the setSomeAttribute() method which overridces this behavior." To change the behavior at this point would effectively break the contract of the class as it's used now. Hence, Sun supplies a new class instead.
Alternately, it could be that changing the behavior to make the synchronization configurable would result in slower performance than either StringBuffer ir StringBuilder currently has. Which would undermine the whole point of adding the new class.
See also recent descussion here. [ August 25, 2004: Message edited by: Jim Yingst ]
"I'm not back." - Bill Harding, Twister
Joined: Oct 01, 2003
OK, you win!
Although I don't have personal knowledge of the decision making involved, here is my guess.
Actually, my guess is that you are right -- on both counts. First, I would guess that they would not want to break (or at least alter) the contract defined by StringBuffer. Second, adding selectable synchronization may be either inefficient, difficult, or both. Furthermore, altering existing, well used, debugged code is risky. Why do it if you don't have to? Adding a new class is a clean solution.