RFR: 7174936: several String methods claim to always create new String

[Brent Christian]

Hi, Stuart

On 11/6/13 5:31 PM, Stuart Marks wrote:
>
> In several places the specs mention returning "new" strings. This is
> overspecified; it's sufficient to return "a" string that satisfies the
> required properties. In some cases the current implementation doesn't
> create a new string -- for example, substring(0) returns 'this' -- which
> is strictly a violation of the spec. The solution is to relax the spec
> requirement to create new strings.

I like it.

I'd like to suggest a doc tweak.

For concat() we have:

--- 1997,2008 ----
        * If the length of the argument string is {@code 0}, then this
!      * {@code String} object is returned. Otherwise, a
!      * {@code String} object is returned, representing a character
        * sequence that is the concatenation of the character sequence

With "new" removed, "Otherwise, a String object is returned, 
representing..." to me somewhat implies that in the other case, 
something other than a String object is returned.

I prefer the way replace() is worded:

--- 2025,2041 ----
        * then a reference to this {@code String} object is returned.
!      * Otherwise, a {@code String} object is returned that
        * represents a character sequence identical to the character

I would change concat() to be similar:
"Otherwise, a String object is returned that represents a character 
sequence that is the concatenation of..."

Thanks,
-Brent