Frequent allocations / promotions of StringCoding$String{Encoder, Decoder} objects

[Xueming Shen]

On 02/25/2016 12:57 PM, Richard Warburton wrote:
> Hi,
>
> Finally, the StringCoding coder c'tor allocates a new Charset coder
>> (Charset{Encoder,Decoder}) for the specific charset. But such Charset
>> coders already seem to be cached in ThreadLocals in the
>> sun.nio.cs.ThreadLocalCoders class. Any reason why we cannot re-use those?
>> (Oh, and also note that this cache does not use SoftReferences, which makes
>> their use by the StringCoding class even more perplexing.)
>>
> +1. I was confused by this behaviour when I submitted a String related
> patch a while back but never got round to submitting a fix. It actually
> means that in String decoding often passing the charset to use by String is
> faster than passing it Charset object - counter-intuitive and less typesafe.
>

We can't cache the "coder" from a passing in charset for security reason.

sherman