Lower overhead String encoding/decoding
Alan.Bateman at oracle.com
Mon Sep 22 11:59:03 UTC 2014
On 22/09/2014 12:25, Richard Warburton wrote:
> I've put together a patch that implements this to demonstrate the overall
> 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.
More information about the core-libs-dev