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

[Richard Warburton]

Hi gents,

public String(ByteBuffer bytes, Charset cs);
>> public String(ByteBuffer bytes, String csname);
>>
>
> I think these constructors make good sense. They avoid an extra copy to an
> intermediate byte[].
>
> One issue (also mentioned by Stephen Colebourne) is whether we need the
> csname overload. Arguably it's not needed if we have the Charset overload.
> And the csname overload throws UnsupportedEncodingException, which is
> checked. But the csname overload is apparently faster, since the decoder
> can be cached, and it's unclear when this can be remedied for the Charset
> case....
>
> I could go either way on this one.
>

Yes - the original motivation for the csname overload was the ability to
cache the decoder and also for consistency with other String encoding
methods that normally have both the String name and also the Charset. If
memory serves me correctly it was concluded that it was possible to cache
the decoder iff the decoder could be trusted to not hold a reference to the
formerly char[], now byte[], that sits within the String. Otherwise a rogue
decoder could create a mutable string by holding a reference to its
internal state for some malicious purpose. JDK charsets aren't rogue so it
would be possible to check whether a charset was a JDK one and perform the
caching, should that be a desirable + worthwhile optimization.

regards,

  Richard Warburton

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