Is it necessary to add the "String csname" variants at this point in Java's lifetime? Don't most people use instances of Charset now?
Stephen On 13 February 2018 at 06:24, Xueming Shen <xueming.s...@oracle.com> wrote: > Hi, > > Please help review the proposal to add following constructors and methods in > String > class to take ByteBuffer as the input and output data buffer. > > public String(ByteBuffer bytes, Charset cs); > public String(ByteBuffer bytes, String csname); > public int getBytes(byte[] dst, int offset, Charset cs); > public int getBytes(byte[] dst, int offset, String csname); > public int getBytes(ByteBuffer bytes, Charset cs); > public int getBytes(ByteBuffer bytes, Charset csn); > > This is based on the change proposed by Richard in jdk9 time frame [1]. But > since > we were fully occupied by compact string support work back then, this one > did > not make into the top jdk9 priority list. > > issue: https://bugs.openjdk.java.net/browse/JDK-8021560 > webrev: http://cr.openjdk.java.net/~sherman/8021560/webrev > > The implementation in StringCoding class is a little "duplicated" for > various types > of encoding/decoding variants. There is definitely room to further > consolidate. But > I would assume it might be better to keep the new code path separated from > the > existing "fully tuned" methods, for now, to avoid possible performance > regression > for existing String methods. > > Thanks, > Sherman > > [1] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-November/029672.html
