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

[Stephen Colebourne]

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.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