On 2/15/18, 1:55 PM, Stuart Marks wrote:
On 2/13/18, 12:41 AM, Alan Bateman wrote:
These four methods encode as many characters as possible into the
destination byte[] or buffer but don't give any indication that the
destination didn't have enough space to encode the entire string. I
thus worry they could be a hazard and result in buggy code. If there
is insufficient space then the user of the API doesn't know how many
characters were encoded so it's not easy to substring and call
getBytes again to encode the remaining characters. There is also the
issue of how to size the destination. What would you think about
having them fail when there is insufficient space? If they do fail
then there is a side effect that they will have written to the
destination so that would need to be documented too.
I share Alan's concern here.
If the intent is to reuse a byte[] or a ByteBuffer, then there needs
to be an effective way to handle the case where the provided
array/buffer doesn't have enough room to receive the decoded string. A
variety of ways of dealing with this have been mentioned, such as
throwing an exception; returning negative value to indicate failure,
To add the ref for the discussion. Here is one of the alternatives being
discussed,
to return the "-length", negative value of the space needed to encode
the whole
String, to hint the caller to pass in an appropriately sized buffer
(only the String
APIs are updated). This appears to be a better than the proposed
"partial fill"/encode
as many as possible approach. But it will still force the caller to take
care of the
return value and manage the possible buffer size issue himself, which
triggers the
question that whether or not the CharsetDecoder is a better place for
such kind of
use scenario.
http://cr.openjdk.java.net/~sherman/8021560/webrev.v2
-Sherman
