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

[Remi Forax]

Hi Tony, hi Richard,
i think it's a security feature,
otherwise you can create a rogue encoder that will be used for a Charset like UTF-8.

regards,
Rémi 


----- Mail original -----
> De: "Richard Warburton" <richard.warburton at gmail.com>
> À: "Tony Printezis" <tprintezis at twitter.com>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoyé: Jeudi 25 Février 2016 21:57:56
> Objet: Re: Frequent allocations / promotions of StringCoding$String{Encoder,	Decoder} objects
> 
> 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.
> 
> regards,
> 
>   Richard Warburton
> 
>   http://insightfullogic.com
>   @RichardWarburto <http://twitter.com/richardwarburto>
>