hg: jdk8/tl/jdk: 6924259: Remove offset and count fields from java.lang.String

Zhong Yu 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.

Wow!

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
on it.

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
their code.

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?

Zhong Yu



More information about the core-libs-dev mailing list