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>
