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
