hg: jdk8/tl/jdk: 6924259: Remove offset and count fields from java.lang.String
zhong.j.yu at gmail.com
Fri Nov 23 15:38:53 UTC 2012
I just realized that I also use String.trim() a lot, and have always
assumed it's very cheap; that's no longer the case.
JDK itself contains many usages of trim(); even a lot of
On Wed, Nov 14, 2012 at 9:14 AM, Zhong Yu <zhong.j.yu at gmail.com> 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
> 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
> 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