See also: https://shipilev.net/jvm/anatomy-quarks/19-lock-elision/ Here StringBuffer is also mentioned: https://www.beyondjava.net/escape-analysis-java
Uwe ----- Uwe Schindler Achterdiek 19, D-28357 Bremen https://www.thetaphi.de eMail: [email protected] > -----Original Message----- > From: Uwe Schindler <[email protected]> > Sent: Monday, June 8, 2020 3:09 PM > To: [email protected] > Subject: RE: StringBuffer usage > > Hi, > > I think, it might be still a good idea to review the uses of StringBuffer. I > think > they might be some relics from former times. I converted all StringBuffers > long > ago in Lucene and I think also in Solr (that was when "heavy committing" was > mentioned for first time by Simon). > > It is not a bad idea to add a forbiddenapis check on the class name, but then > we > need some @SuppressWarnings at places where legacy APIs like formatting or > regular expressions in Java are used (famous example is > Matcher#appendReplacement). That's also one reason why there's no default > signature to forbid those. In addition the class is not deprecated because of > the > many APIs as described above. > > Uwe > > P.S.: Using a StringBuilder or StringBuffer from multiple threads is always a > bad > idea, so this should not be the limiting factor here! :-] > P.P.S.: If there would be a speed problem, JDK devs would have fixed Matcher, > Formatter & Co already. Introduction of StringBuilder in JDK 5 was a > shortcoming, because with Java 6 the escape analysis was added to Hotspot. > > ----- > Uwe Schindler > Achterdiek 19, D-28357 Bremen > https://www.thetaphi.de > eMail: [email protected] > > > -----Original Message----- > > From: Erick Erickson <[email protected]> > > Sent: Sunday, June 7, 2020 9:23 PM > > To: [email protected] > > Subject: Re: StringBuffer usage > > > > 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 <[email protected]> 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 > > <[email protected]>: > > > 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: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > > > -- > > > Uwe Schindler > > > Achterdiek 19, 28357 Bremen > > > https://www.thetaphi.de > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
