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

Remi Forax forax at univ-mlv.fr
Wed Nov 14 16:06:10 UTC 2012

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 oldsubstring() method that preserves O(1). Unfortunately oldsubstring() 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

More information about the core-libs-dev mailing list