Patch: Updated `String +' patch

[Tom Tromey]

>>>>> "Eric" == Eric Blake <ebb9@email.byu.edu> writes:

Eric> Notice that java.lang.StringBuffer(Object) and
Eric> StringBuffer(String) do not gracefully handle null, so the
Eric> compiler must use new StringBuffer().append(o).  But is there
Eric> any reason that we can't make gnu.gcj.runtime.StringBuffer(o)
Eric> work properly?

I did this.

Eric> I agree with Per; lose the shared flag.

Done.

>> +   Copyright (C) 1998, 1999, 2000, 2001 Free Software Foundation, Inc.

Eric> I'm no copyright lawyer, but are all those dates necessary for a
Eric> new file?

Yes, because this file is derived from the other StringBuffer.java.

Eric> Would this be more efficient as:
Eric> return append(bool ? "true" : "false");

Done.

Eric> Similarly, could this call be made as: return
Eric> append(Long.toString(lnum)); to save a method call on the stack?
Eric> (Similar comments for the other methods).

Done.

Eric> Of course, here the compiler may have already determined that
Eric> when optimizing...

Right now inlining doesn't work very well.  So doing this by hand is
ok.

Eric> Rather than calling str.length(), couldn't you use str.count, as
Eric> it is package visible?

Nope, since this StringBuffer is in a different package.

>> +  public StringBuffer append (char[] data)
>> +  {
>> +    return append (data, 0, data.length);
>> +  }

Eric> Why do you need this? String concatenation never uses it:

An oversight; I deleted it.

Thanks for your comments.
I'll check in the patch today.

Tom