Hi all, I've written up the summary of this thread as part of the pre-review checklist here:
http://java.net/projects/jugs/pages/StringBufferToStringBuilderReplacements Any comments/questions/feedback is welcome! Cheers, Martijn On 10 May 2012 12:55, Joel Borggren-Franck <[email protected]> wrote: > Hi, > > "Tobias Frech" <[email protected]> writes: > >> Hi, >> concerning the safety of replacing StringBuffers with StringBuilders: >> not only should these StringBuffers not escape the method they are >> created in. But also they should not be assigned to an instance or >> static field of the class in this method or any other method which is >> called from within that method. > > If you assign a StringBuffer to a field then it is escaping. In this > context escaping means getting out of the method it is a local variable > in. > > There are many ways the StringBuffer can escape: > > - By assignment to a field > - By using it as a parameter to a method/constructor > - With an exception that gets thrown > - By assign it to an array that isn't local and provably non-escaping > - By returning it > > (there may be other ways I haven't thought of ...) > > In some of this cases the StringBuffer could be proven to not escape by > further analysis but this is very easy to get wrong. So for this > purpose, if it has a chance of leaving the method the StringBuffer is a > local variable in, consider it as escaping. > > Expanding a bit on this: > > You have two cases: > > 1) The StringBuffer provably doesn't escape. In this case as others have > said, the conversion will be safe. Beware of aliasing, in general there > can be many references to the same StringBuffer, none of them can > escape. > > 2) Given that the StringBuffer can escape, the transformation isn't > automatically safe, but neither automatically unsafe. But in this case > the analysis gets much more complicated. It might not be worth the > effort. The VM is very good at reducing cost for locks used only by one > thread. So if your escaping StringBuffer doesn't require the > synchronization then you won't loose that much by having it synchronize > (but if you actually need it well then the conversion wasn't safe to > begin with). > > As Mike wrote: > >> On 4 May 2012 17:05, Mike Duigou <[email protected]> wrote: > >>> >>> I think that for the most part you have it covered by ensuring that >>> the StringBuffer instances are all ones that don't escape the method >>> in which they are created. >>> > > Thanks to all the volunteers for getting involved in this! > > /cheers > Joel
