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.warbur...@gmail.com>
> À: "Tony Printezis" <tprinte...@twitter.com>
> Cc: "core-libs-dev" <core-libs-dev@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>
>
