3 Replies Latest reply: Oct 15, 2012 4:19 PM by DrClap RSS

    StringBuffer StringBuilder

    gbishop
      It would have been really nice if these basically identical classes had implemented a common interface.

      The fact they don't makes swapping them out a bit of a pain if you have a utility class that uses them where you actually need the threadsafe behavior of StringBuffer sometimes.

      You can of course use [Duck Typing|http://en.wikipedia.org/wiki/Duck_typing] , but that's a pain. It's nice to know that the Duck Typing technique exists though. Another alternative is to create an interface that is common to both implementations of your utility class and then 2 specific implementations, but that duplicates code, or you can wrap the StringBuffer and StringBuilder in a Delegator, but that's even more code. You can't extend them because they are final. And the darn things don't even override the equals method which I think is crazy.

      Edited by: user10739046 on Oct 15, 2012 8:34 AM
        • 1. Re: StringBuffer StringBuilder
          jtahlborn
          user10739046 wrote:
          The fact they don't makes swapping them out a bit of a pain if you have a utility class that uses them where you actually need the threadsafe behavior of StringBuffer sometimes.
          you actually have code which depends on the thread-safe behavior of StringBuffer? you have multiple threads trying to simultaneously append the same StringBuffer instance?
          • 2. Re: StringBuffer StringBuilder
            939520
            I think your over complicating your life by trying to use a common interface or similar gimmick. I don't even think its a good idea to put StringBuilder/StringBuffer in a utility class. I suggest instead you use StringBuilder directly everywhere unless you specifically have a situation that justifies StringBuffer. This way, the code maintainer that comes after you will not go nuts trying to decide which is a thread issue and which isn't. Additionally, you might want to put a comment above each use of StringBuffer saying why you are using it instead of StirngBuilder. This way, the code maintainer realizes you have a justification for using it and didn't accidently use it instead of StringBuilder.
            • 3. Re: StringBuffer StringBuilder
              DrClap
              I don't know what your actual requirements are for having a StringBu***er shared by more than one thread, but just synchronizing all the methods of an object doesn't always provide adequate thread-safety. For example it's possible that you may want to do something like
              builder.append("foo").append(bar.toString().toLowerCase())
              in an atomic way (i.e. "foo" comes immediately before that bar-value with nothing in between), in which case relying on the fact that the append() method of StringBuffer is synchronized isn't good enough.

              In other words since you have to consider thread-safety issues like this, perhaps you might as well just use StringBuilder throughout. This would force you to consider thread-safety properly, instead of being lulled into complacency by the faux thread-safety provided by StringBuffer.