Uwe:
In that case we can ignore the question, this was just a reflex on my part.
> On Jun 7, 2020, at 11:38 AM, Uwe Schindler <u...@thetaphi.de> wrote:
>
> Hi,
>
> The main reason to use StringBuffer ist legacy Apis. One example is all
> Formatters low level apis (DecimalFormat, Formatter,...) Use StringBuffer to
> implement itsself.
>
> Nowadays there is no performance impact anymore. If you use StringBuffer from
> one thread, JVM removes the synchronization.
>
> Uwe
>
> Am June 7, 2020 2:46:20 PM UTC schrieb Bram Van Dam <bram.van...@intix.eu>:
> On 06/06/2020 22:48, Erick Erickson wrote:
> When is there a good reason to use StringBuffer rather than StringBuilder?
> While going through some of the warnings I happened to run across a few of
> these. I haven’t changed them, and at least one (AuditEvent) has a comment
> about back-compat and is quite recent…
>
> StringBuffer hardly ever makes sense. Sure, it's synchronized, but it
> usually doesn't do what you want.
>
> If Thread 1 and Thread 2 each call
>
> sb.append("1");
> sb.append("2");
> sb.append("3");
>
> the result likely won't be "123123". Appending each individual append
> operation is synchronized and "safe", but multiple consecutive calls are
> not. So unless you're either using an external synchronization
> mechanism, or are appending things "atomically", you can still get
> screwed. With that in mind, StringBuffer's synchronization is almost
> always useless overhead.
>
> - Bram
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
> --
> Uwe Schindler
> Achterdiek 19, 28357 Bremen
> https://www.thetaphi.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
