RFR: JDK-8021560,(str) String constructors that take ByteBuffer

[Xueming Shen]

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