Hacker News Reader

Comment by haspok | Hacker News Reader

How would you fix this? Possibly by copying the input array to a local array as the first step? But then you might copy a lot of data, which is in 99% of the cases totally unnecessary. Have a separate threadsafe and a non-threadsafe constructor for char[]?

EDIT: another idea is to do a hash of the input array, and compare between start and end. But that also requires an O(n) walk through the input...

View on HN

> But that also requires an O(n) walk through the input...

Compressing requires an O(n) walk through the input either way.

Yes. In fact, both String.valueOf(char[]) and constructor String(char[]) are already documented as copying the array contents.

/s redesign a language to prevent parallel mutable use of the array

This won't happen (unfortunately) for obvious reasons.

I'm not sure how much of the underlying implementation details of arrays are leaking into JNI, but one way to approach it would be with first class copy-on-write for arrays or opt-in immutability (freezing).

> How would you fix this? Possibly by copying the input array to a local array as the first step?

Upon encountering a non-Latin1 char, convert the existing latin1 array to an utf16 one, append the char (converted), then resume iteration in utf16 copy mode.

This way you know the char which made you bail out on Latin1 is part of the output.

Copy the array, then use alias analysis to remove the copy most of the time, by having two versions of the String constructor, with a version chosen based on aliasing.

Reply on news.ycombinator.com