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

Richard Warburton richard.warburton at
Thu Feb 25 20:57:56 UTC 2016


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.


  Richard Warburton
  @RichardWarburto <>

More information about the core-libs-dev mailing list