RFR(2): 7174936: several String methods claim to always create new String

Stuart Marks stuart.marks at oracle.com
Thu Nov 21 04:04:25 UTC 2013

On 11/15/13 8:36 AM, Alan Bateman wrote:
> On 14/11/2013 23:56, Stuart Marks wrote:
>> On 11/14/13 2:04 AM, David Holmes wrote:
>>> 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.
>> Yes, in general, what you say about weakening post-conditions is true. In this
>> case, though, I can't see how it can cause any practical harm.
> I've looked through the webrev and read the exchange between you and David.
> I think it might be better to leave the subSequence change out for now (the
> @apiNote is fine) and submit another bug to track the discrepancy between the
> spec and implementation. From what I can tell, this has existed since
> CharSequence was added in 1.4, in which case there may be a good argument to
> just document the potential deviation.

OK, I'll remove the String.subSequence change from this changeset and push it 
when I get approval.

I've filed this bug:


to cover the CharSequence.subSequence issue and potential spec change. It 
probably isn't that much work to do, but it probably is easier to handle it 


More information about the core-libs-dev mailing list