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
str.substring().trim()
Just saying.
On Wed, Nov 14, 2012 at 9:14 AM, Zhong Yu <zhong.j...@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
> 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
