Lower overhead String encoding/decoding

Richard Warburton richard.warburton at gmail.com
Thu Sep 25 14:48:24 UTC 2014

Hi Alan,

Thanks for the feedback.

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.

I've updated the webrev to reflect this, removing the offset and length
parameters and using position() and limit() instead.


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.

I've also applied the this to the getBytes() method. I chose the getBytes()
method name for consistency with the existing getBytes() method that
returns a byte[]. To my mind encode() is a more natural name for the
method, which you mention in your email, do people have a preference here?


  Richard Warburton

  @RichardWarburto <http://twitter.com/richardwarburto>

More information about the core-libs-dev mailing list