«

On 7/3/2011 11:23 PM, lbrt chx _ gemale kom wrote:

>>> ~ We have all learned we should avoid String(s) and use
>>> StringBuffer(s) or better yet StringBuilder(s) but there is
> ~
>> Er, no. Strings are great ...
> ~
> I (obviously) meant to say String(s) if you need to build them andStringBuilder(s)
> if you are working (most of us by now) on some multiprocessing core
> ~

If you need to build them, you'd need a StringBuilder. And if you need
support for multiple threads AND need to modify them, you'd need a
StringBuffer.

On 7/4/2011 12:15 AM, Patricia Shanahan wrote:
> On 7/3/2011 11:33 AM, Abu Yahya wrote:
>> On 7/3/2011 11:23 PM, lbrt chx _ gemale kom wrote:
>>
>>>>> ~ We have all learned we should avoid String(s) and use
>>>>> StringBuffer(s) or better yet StringBuilder(s) but there is
>>> ~
>>>> Er, no. Strings are great ...
>>> ~
>>> I (obviously) meant to say String(s) if you need to build them
>>> andStringBuilder(s)
>> > if you are working (most of us by now) on some multiprocessing core
>>> ~
>>
>> If you need to build them, you'd need a StringBuilder. And if you need
>> support for multiple threads AND need to modify them, you'd need a
>> StringBuffer.
>
> Often, the StringBuffer locking is not strong enough to be really
> useful. If, for example, a thread needs to append two strings to the
> buffer and have them appear consecutively in the resulting string, it
> needs synchronization at a higher level.

True. StringBuffer's locking will only help in guaranteeing an output in
which either the first string /or/ the second string is /completely/
appended first. If the order matters, the built-in locking won't help.

On Jul 3, 11:33*am, Abu Yahya <abu_ya...@invalid.com> wrote:
> On 7/3/2011 11:23 PM, lbrt chx _ gemale kom wrote:
>
> >>> ~ We have all learned we should avoid String(s) and use
> >>> StringBuffer(s) or better yet StringBuilder(s) but there is
> > ~
> >> Er, no. *Strings are great ...
> > ~
> > * I (obviously) meant to say String(s) if you need to build them andStringBuilder(s)
>
> *> *if you are working (most of us by now) on some multiprocessing core
>
> > ~
>
> If you need to build them, you'd need a StringBuilder. And if you need
> support for multiple threads AND need to modify them, you'd need a
> StringBuffer.

Well, no. You might want a 'StringBuffer', but it's hardly a need.

--
Lew

Abu Yahya wrote:
> Patricia Shanahan wrote:
>> Abu Yahya wrote:
>>> If you need to build them, you'd need a StringBuilder. And if you need
>>> support for multiple threads AND need to modify them, you'd need a
>>> StringBuffer.
>

>> Often, the StringBuffer locking is not strong enough to be really
>> useful. If, for example, a thread needs to append two strings to the
>> buffer and have them appear consecutively in the resulting string, it
>> needs synchronization at a higher level.
>

> True. StringBuffer's locking will only help in guaranteeing an output in
> which either the first string /or/ the second string is /completely/
> appended first. If the order matters, the built-in locking won't help.

That's a small part of the story, and not accurate anyway.

StringBuffer sb;
...
sb.append( firstString ).append( secondString );

/happens-before/ guarantees that the second 'append()' will
concatenate after the first one. Once the second 'append()'
completes, all threads are guaranteed to see the effects of both
'append()'s. The synchronization inbuilt to 'StringBuffer' does not
guarantee that some thread won't intervene between the two
'append()'s.

--
Lew

On 7/3/2011 2:45 PM, Patricia Shanahan wrote:
> On 7/3/2011 11:33 AM, Abu Yahya wrote:
>> On 7/3/2011 11:23 PM, lbrt chx _ gemale kom wrote:
>>
>>>>> ~ We have all learned we should avoid String(s) and use
>>>>> StringBuffer(s) or better yet StringBuilder(s) but there is
>>> ~
>>>> Er, no. Strings are great ...
>>> ~
>>> I (obviously) meant to say String(s) if you need to build them
>>> andStringBuilder(s)
>> > if you are working (most of us by now) on some multiprocessing core
>>> ~
>>
>> If you need to build them, you'd need a StringBuilder. And if you need
>> support for multiple threads AND need to modify them, you'd need a
>> StringBuffer.
>
> Often, the StringBuffer locking is not strong enough to be really
> useful. If, for example, a thread needs to append two strings to the
> buffer and have them appear consecutively in the resulting string, it
> needs synchronization at a higher level.

StringBuffer is better than StringBuilder in the case where
if >1 threads append N characters to it, then you are happy
if you get N characters appended don't care about the order.
That is practically never the case. The order of characters
is almost always significant.

Arne