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. http://cr.openjdk.java.net/~rwarburton/string-patch-webrev-6/ 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? regards, Richard Warburton http://insightfullogic.com @RichardWarburto <http://twitter.com/richardwarburto>
