RFR(2): 7174936: several String methods claim to always create new String
david.holmes at oracle.com
Thu Nov 14 01:04:04 UTC 2013
Sorry for the delay (been enroute). Only issue I have remains the
subSequence change - you can't weaken the post-condition of
CharSequence.subSequence without breaking subtype substitutability.
On 12/11/2013 8:43 AM, Stuart Marks wrote:
> Hi all,
> Here's an updated version of the String spec change. Changes from the
> previous version address comments made by Brent Christian and David
> Holmes. Specifically:
> - Specify copyValueOf() overloads as "equivalent to" corresponding
> valueOf() overloads.
> - Remove extranous changes to subSequence() method
> - Clarify wording of concat() method doc.
> Bug report:
> On 11/7/13 2: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
>> 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
>> 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.
>> This change is spec only, no code changes.
>> Bug report:
More information about the core-libs-dev