hg: jdk8/tl/jdk: 6924259: Remove offset and count fields from java.lang.String

[Remi Forax]

Hi Zhong Yu,
I agree with you that changing the implementation of something
like String.substring which is widely used is something that is always a 
little hairy.

The memory leak you mention is one side of the problem, the other is that
we want the VM to do memory collocation of String (i.e. allocate the 
array of char
and the String as one object to avoid the double indirection).
For that the creation of the char array and the creation of the String
must be done in the constructor of String.

So this change is a way to look to the bright future instead of looking 
to the dark past :)

Now, I don't know why this change was backported to a jdk update,
but it's more a question to the jdk7 update mailing list.

Rémi

On 11/14/2012 04:14 PM, Zhong Yu wrote:
> Changing String.substring() from O(1) to O(n) is a big deal; we may
> say it breaks compatibility.
>
> Any code that intends to work across JDK versions before and after 7u6
> cannot use the method, since its behavior is so different in different
> versions.
>
> Any deployment that upgrades JDK to 7u6 and later needs to review all
> its usages of substring(). That's a ton of work. A quick workaround
> might be to refactor all substring() usages to some `old_substring()`
> method that preserves O(1). Unfortunately `old_substring()` cannot
> exist, so there's no quick workaround possible.
>
> The memory leak problem of the old substring() method is well-known
> among Java programmers, it's not really a big problem today.
>
> For the uninitiated, they might expect that substring() is leak-free;
> but they might also expect that substring() is O(1). There's no
> apparent reason why favoring one is better than favoring the other.
>
> In the old implementation, there's a workaround to achieve leak-free,
> by `new String(String)`.
>
> In the new implementation, there is no workaround to achieve O(1),
> unless the developer uses something other than String. It is basically
> impossible to change String to another type if it's part of a method
> signature.
>
> With all these problems, please reconsider this change and see if you
> should roll it back. Thanks.
>
> Zhong Yu