Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!.POSTED!not-for-mail
From: Jan Burse <janburse@fastmail.fm>
Newsgroups: comp.lang.java.programmer
Subject: Re: StringBuilder
Date: Sun, 18 Sep 2011 15:32:12 +0200
Organization: albasani.net
Lines: 58
Message-ID: <j54rss$j3q$1@news.albasani.net>
References: <96f358c8-a024-40db-b60b-300186c2f813@o10g2000vby.googlegroups.com> <j41fik$3qb$1@news.albasani.net> <j52jgd$iij$1@dont-email.me> <vp7a77lp3e5oe4h79pnmv95vb4lu13spmc@4ax.com> <GeednbWNqODBGOjTnZ2dnUVZ_rqdnZ2d@posted.palinacquisition> <j54nc9$tgk$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.albasani.net Yp6jBuh8rr9R7VI6Xp3lZ5aAQHFDkMzSemwmXxHBtfAKaqFC6PNvSDoWpbW1Wx5F7u3u1aEd771720bZgXtkoODlBNFpuWdKGB36+lYRsp3jGl5AZdlhKvpe0f+BFdec
NNTP-Posting-Date: Sun, 18 Sep 2011 13:32:12 +0000 (UTC)
Injection-Info: news.albasani.net; logging-data="6yw+fQu7iZM031JutPpAz6DK0qwZ81oNIHCgCGqBR5YwTfiXP0larGLPAXacOpJer4gK097RkILy5yY9+Ox2U4Ne6M13v8HQGxKptqY2ta6JHR/NahzBDT3EvORMxxPY"; mail-complaints-to="abuse@albasani.net"
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Firefox/6.0.2 SeaMonkey/2.3.3
In-Reply-To: <j54nc9$tgk$1@dont-email.me>
Cancel-Lock: sha1:EhWW7RYbH+6M7WKBwSOwScof238=
Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:8125

Eric Sosman schrieb:
> I don't have old Java source, but I do have an old O'Reilly
> book ("Java In a Nutshell, 2nd Edition, Covers Java 1.1, by David
> Flanagan") that states
>
> The StringBuffer.toString() method does not copy the internal
> array of characters; instead it shares that array with the
> new String object, and makes a new copy for itself only when
> further modifications are made to the StringBuffer object.
>
> Assuming the author was correct, it follows that the implementation
> changed at some later point. Presumably, that change was driven by
> evidence that the "optimization" wasn't worth while.

I guess first of all probably a reengineering was done, and
StringBuffer was split into AbstractStringBuilder and StringBuffer.
And then StringBuilder was created. The class diagramm is basically:

          AbstractStringBuilder
          /                    \
      StringBuffer             StringBuilder

Most of the StringBuffer methods are synchronized and then delegate
to the abstract super class. In StringBuilder the methods are
non-synchronized and then also delegate to the abstract super class.

The delegation instead of just using the methods from the abstract
class is needed so that the correct type is returned. For example
the AbstractStringBuilder does have an append that even returns
an AbstractStringBuilder. But it is then overridden by a method that 
returns StringBuffer respectively StringBuilder.

So we see for example:

     In StringBuffer:

     public synchronized StringBuffer append(char c) {
         super.append(c);
         return this;
     }

     In StringBuilder:

     public StringBuilder append(char c) {
         super.append(c);
         return this;
     }

The necessary overriding capability called covariant return types is
only available since Java 1.5.

http://www.java-tips.org/java-se-tips/java.lang/covariant-return-types.html

So maybe during all this quality language reengineering the aspect
of optimization became less prominent.

Best Regards