RFR: 7174936: several String methods claim to always create new String
David Holmes
david.holmes at oracle.com
Thu Nov 7 02:15:03 UTC 2013
Hi Stuart,
On 7/11/2013 11:31 AM, Stuart Marks wrote:
> Hi all,
>
> Please review the following spec changes to java.lang.String.
>
> 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.
Or modify it as per concat - which is spec'd to return this when you
concat an empty string.
But I suppose in principle this allows for reuse of existing String objects.
> Also, this change cleans up the specs for the copyValueOf() overloads to
> make them identical to the corresponding valueOf() overloads.
> Previously, they were gratuitously different. I think that some time in
> the dim, distant past, probably before JDK 1.0, they had different
> semantics, but now they're identical. The specs should say they're
> identical.
Don't we normally express this as "Equivalent to ..." rather than
"Identical to ..." - the latter seems like an overspecification.
>
> This change is spec only, no code changes.
Surely this change invalidates any tests that check for "new" strings as
per the spec? They won't start failing but they will no longer be valid
test.
That aside subSequence is specified by CharSequence to return a new
CharSequence. So I don't think you can simply remove that requirement.
Cheers,
David
-----
> Bug report:
>
> https://bugs.openjdk.java.net/browse/jdk-7174936
>
> Webrev:
>
> http://cr.openjdk.java.net/~smarks/reviews/7174936/webrev.0/
>
> Specdiff:
>
>
> http://cr.openjdk.java.net/~smarks/reviews/7174936/specdiff.0/overview-summary.html
>
>
> Thanks!
>
> s'marks
More information about the core-libs-dev
mailing list