hg: jdk8/tl/jdk: 6924259: Remove offset and count fields from java.lang.String (original) (raw)
Zhong Yu zhong.j.yu at gmail.com
Wed Nov 14 15:14:42 UTC 2012
- Previous message: hg: jdk8/tl/jdk: 8000404: rename javax.tools.GenerateNativeHeader to java.lang.annotation.Native
- Next message: hg: jdk8/tl/jdk: 6924259: Remove offset and count fields from java.lang.String
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: hg: jdk8/tl/jdk: 8000404: rename javax.tools.GenerateNativeHeader to java.lang.annotation.Native
- Next message: hg: jdk8/tl/jdk: 6924259: Remove offset and count fields from java.lang.String
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]