A DESCRIPTION OF THE REQUEST :
Hello,
The methods newEncoder and newDecoder are not using any form of caching, like provided by the "ThreadLocalCoders".

This means every time a String object is created, a short-living Decoder is also created. Same goes for the "getBytes(Charset)" method, creating a new Encoder object per invocation.

JUSTIFICATION :
Applications working with String objects and (de-)serialisation suffer from GC pressure because of this expensive behaviour: every time a String is encoded or decoded, 2 objects are created (either String+Decoder or byte[]+Encoder)


---------- BEGIN SOURCE ----------
byte[] byteArray = new byte[] {87, 79, 87}; // WOW
String testString = new String(b, Charset.forName("UTF-8"));
/*
This invokes StringCoding.decode, which in turns calls
CharsetDecoder cd = cs.newDecoder();
*/

byte[] b = s.getBytes(Charset.forName("UTF-8"));
/*
This invokes StringCoding.encode, which in turns calls
CharsetEncoder ce = cs.newEncoder();
*/
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
My proposed change would be to either always invoke ThreadLocalCoders in the "new Coder" methods, or to change String so it uses some form of caching.