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

On Sat, Feb 17, 2018 at 4:05 AM, Alan Bateman wrote: > Just to add that the existing low-level / advanced API for this is > CharsetEncoder. The CoderResult from an encode and the buffer positions > means you know when there is overflow, the number of characters encoded,

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

On 16/02/2018 22:55, Richard Warburton wrote: : I think some of the context here around application level memory management of the byte buffers is missing. The getBytes() methods were supposed to be useful in scenarios where you have a String and you want to write the byte encoded version of it

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

On 16/02/2018 21:56, Stuart Marks wrote: : Seems like an argument that this function is in the wrong location. (Not joking.) I think CharBuffer.toString() is actually quite obscure. I note that most of the Buffer classes have toString() methods that report the *status* of the buffer, e.g.

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

On 02/16/2018 03:04 PM, Richard Warburton wrote: Hi gents, public String(ByteBuffer bytes, Charset cs); public String(ByteBuffer bytes, String csname); I think these constructors make good sense. They avoid an extra copy to an intermediate byte[]. One issue (also

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

Hi gents, public String(ByteBuffer bytes, Charset cs); >> public String(ByteBuffer bytes, String csname); >> > > I think these constructors make good sense. They avoid an extra copy to an > intermediate byte[]. > > One issue (also mentioned by Stephen Colebourne) is whether we need the > csname

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

Hi gents, Thanks Sherman for taking up the bat on this one - most appreciated. These four methods encode as many characters as possible into the destination byte[] or buffer but don't give any indication that the destination didn't have enough space to encode the entire string. I thus

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

On 2/16/18 6:14 AM, Alan Bateman wrote: On 15/02/2018 21:55, Stuart Marks wrote: I'd also suggest adding a CharBuffer constructor:     public String(CharBuffer cbuf) This would be semantically equivalent to     public String(char[] value, int offset, int count) except using the chars from

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

On 15/02/2018 21:55, Stuart Marks wrote: : I'd also suggest adding a CharBuffer constructor:     public String(CharBuffer cbuf) This would be semantically equivalent to     public String(char[] value, int offset, int count) except using the chars from the CharBuffer between the buffer's

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

On 2/16/18, 5:58 AM, Ulf Zibis wrote: Hi, what is the difference of: - class StringCoding - class StringCoder - class StringCoding.StringDecoder - class StringCoding.StringEncoder Why we need so much variants of redundant code? I think it would be useful to have some explanation in the

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

Hi, what is the difference of: - class StringCoding - class StringCoder - class StringCoding.StringDecoder - class StringCoding.StringEncoder Why we need so much variants of redundant code? I think it would be useful to have some explanation in the javadoc. Missing indentation in

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

On 2/15/18, 1:55 PM, Stuart Marks wrote: On 2/13/18, 12:41 AM, Alan Bateman wrote: These four methods encode as many characters as possible into the destination byte[] or buffer but don't give any indication that the destination didn't have enough space to encode the entire string. I thus

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

public String(ByteBuffer bytes, Charset cs); public String(ByteBuffer bytes, String csname); I think these constructors make good sense. They avoid an extra copy to an intermediate byte[]. One issue (also mentioned by Stephen Colebourne) is whether we need the csname overload. Arguably it's

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

On 2/13/18, 12:41 AM, Alan Bateman wrote: 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); These four methods encode as

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

On Tue, Feb 13, 2018 at 2:41 AM, Alan Bateman wrote: > On 13/02/2018 06:24, Xueming Shen 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. >> >>

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

On 13/02/2018 06:24, Xueming Shen 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); These

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

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 wrote: > Hi, > > Please help review the proposal to add following constructors and

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

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,