Lower overhead String encoding/decoding

[Alan Bateman]

On 22/09/2014 12:25, Richard Warburton wrote:
> :
>
> I've put together a patch that implements this to demonstrate the overall
> direction.
>
> http://cr.openjdk.java.net/~rwarburton/string-patch-webrev-5/
>
> I'm happy to take any feedback on direction or the patch itself or the
> overall idea/approach. I think there are a number of similar API situations
> in other places as well, for example StringBuffer/StringBuilder instances
> which could have similar appends directly from ByteBuffer instances instead
> of byte[] instances.
>
The direction seems reasonable but I wonder about the offset/length (and 
destOffet) parameters as this isn't consistent with how ByteBuffers were 
originally intended to be used. That is, when you read the bytes from 
the wire into a ByteBuffer and flip it then the position and limit will 
delimit the bytes to be decoded.

If the constructor is changed to String(ByteBuffer in, Charset cs) and 
decodes the remaining bytes in the buffer to a String using the 
specified Charset then I think would be more consistent. Also I think 
this would give you a solution to the underflow case.

Similarly if getBytes is replaced with with a getBytes or 
encode(ByteBuffer, Charset cs) then then it would encode as many 
characters as possible into the output buffer and I think would be more 
consistent and also help with overflow case.

-Alan.