RFR: JDK-8021560,(str) String constructors that take ByteBuffer

Stephen Colebourne scolebourne at joda.org
Tue Feb 13 08:13:35 UTC 2018

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?


On 13 February 2018 at 06:24, Xueming Shen <xueming.shen at 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

More information about the core-libs-dev mailing list