hg: jdk8/tl/jdk: 6924259: Remove offset and count fields from java.lang.String
zhong.j.yu at gmail.com
Thu Nov 8 17:22:03 UTC 2012
On 06/03/2012 11:35 PM, Mike Duigou wrote:
> [I trimmed the distribution list]
> On Jun 3 2012, at 13:44 , Peter Levart wrote:
>> On Thursday, May 31, 2012 03:22:35 AM mike.duigou at oracle.com wrote:
>>> Changeset: 2c773daa825d
>>> Author: mduigou
>>> Date: 2012-05-17 10:06 -0700
>>> URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2c773daa825d
>>> 6924259: Remove offset and count fields from java.lang.String
>>> Summary: Removes the use of shared character array buffers by String along
>>> with the two fields needed to support the use of shared buffers.
>> Wow, that's quite a change.
> Indeed. It was a long time in development. It is a change which is expected to be overall beneficial though and in the general case a positive win.
If the previous behavior of substring() was once a bug, by now it has
become a well known feature. People know about it, and people depend
This change is a big surprise. Changing O(1) to O(n) is a breach of
contract. It'll break lots of old code; and meanwhile lots of new code
are still being written based on the old assumption. After people
learned about the new behavior, they need to comb through and rewrite
The worst part is the same code performs very differently on different
versions of JDK. What's a programmer supposed to do if his code
targets JDK6 and above? If the cost of strings are no longer certain,
what else can we believe in?
Is there any chance in hell to roll it back? Maybe add a new method
for the new behavior?
More information about the core-libs-dev