Lower overhead String encoding/decoding

Richard Warburton richard.warburton at gmail.com
Sun Oct 26 21:10:25 UTC 2014

Hi Alan,

I think this looks better but I have a few comments on the API.

Thanks for taking the time to look at this - most appreciated. I've pushed
the latest iteration to

For String(ByteBuffer, Charset) then it's still inconsistent to read from
> the buffer position but not advance it. I think the constructor needs to
> work like a regular decode in that respect. Related to this is the
> underflow case where there are insufficient remaining bytes to complete. If
> you don't advance the position then there is no way to detect this.

I've modified the Javadoc and tests. The implementation was actually
behaving this way already.

The statement about the length of the String ".. may not be equal to the
> length of the subarray" might  be there from a previous iteration. There
> isn't any array in the method signature so I think this statement needs to
> be make a bit clearer.

I've rephrased this to refer to the ByteBuffer.

For getBytes(byte[], int, int, Charset) then I think the javadoc could say
> a bit more. It will encode to a maximum of destBuffer.length - destOffset
> for example. The @return should probably say that it's the number of bytes
> written to the array rather than "copied".  Minor nits is that you probably
> don't want the starting <p>. Also the finals in the signature seem
> noisy/not needed.

> The getBytes(ByteBuffer, Charset) method needs a bit more javadoc. You
> should be able to borrow from text from the CharsetEncoder#encode methods
> to help with that.

I've updated the Javadoc with more information about the encoding and made
these changes. I'm not sure if there's anything else that's missing in this


  Richard Warburton

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

More information about the core-libs-dev mailing list