The new implementation also introduces a new form of memory leak. Previously N substrings take O(N) space. Now it takes O(N*m) space where m is the average length of substrings.
Some applications may be double penalized by the new implementation - both CPU and memory go up. 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