Hi,
I'm still planning to be the sponsor for this RFE and get this one
into the jdk9. We are current working on JEP 254 [1][2][3]in which
the internal storage mechanism is changed from char[] to byte[]. If
this JEP get approved and is scheduled to target JDK9, the
decoding/encoding
Hi gents,
My apology for the delay, things are little slow during this period of the
year:-)
I will sponsor the rfe and prepare for the CCC (internally). We may need
go through
the api and the implementation one more time.
I was just wondering if there was any news on the CCC for this
Richard,
I'm still planning to be the sponsor for this RFE and get this one into
the jdk9. We are current working on
JEP 254 [1][2][3]in which the internal storage mechanism is changed from
char[] to byte[]. If this JEP get
approved and is scheduled to target JDK9, the decoding/encoding
On 06/03/2015 07:34 PM, Xueming Shen wrote:
I'm still planning to be the sponsor for this RFE and get this one
into the jdk9. We are current working on JEP 254 [1][2][3]in which
the internal storage mechanism is changed from char[] to byte[]. If
this JEP get approved and is scheduled to
Hi Xueming,
My apology for the delay, things are little slow during this period of the
year:-)
I will sponsor the rfe and prepare for the CCC (internally). We may need
go through
the api and the implementation one more time.
I was just wondering if there was any news on the CCC for this
On 12/30/14 3:25 PM, Richard Warburton wrote:
Hi,
Thanks for looking at this patch and agreeing to sponsor - I've
pushed fixes for these issues at:
http://cr.openjdk.java.net/~rwarburton/string-patch-webrev-10/
http://cr.openjdk.java.net/%7Erwarburton/string-patch-webrev-10/
Hi,
Thanks for looking at this patch and agreeing to sponsor - I've pushed
fixes for these issues at:
http://cr.openjdk.java.net/~rwarburton/string-patch-webrev-10/
Hope everyone has had a happy holiday period. Just following up on this
issue to make sure that you have all the information
Hi gents,
Here are some comments regarding the updated webrev.
(1) String(ByteBuffer, String) needs @throw UEE.
(2) It should be default replacement byte array not replace string
for all
getBytes() methods when malformed/unmappable
(3) for decoding (new String) from ByteBuffer, since
Hi Richard,
Here are some comments regarding the updated webrev.
(1) String(ByteBuffer, String) needs @throw UEE.
(2) It should be default replacement byte array not replace string for all
getBytes() methods when malformed/unmappable
(3) for decoding (new String) from ByteBuffer, since it
On 24/11/2014 18:41, Xueming Shen wrote:
Hi Richard,
Here are some comments regarding the updated webrev.
(1) String(ByteBuffer, String) needs @throw UEE.
(2) It should be default replacement byte array not replace string
for all
getBytes() methods when malformed/unmappable
(3) for
On 11/24/2014 01:21 PM, Alan Bateman wrote:
On 24/11/2014 18:41, Xueming Shen wrote:
Hi Richard,
Here are some comments regarding the updated webrev.
(1) String(ByteBuffer, String) needs @throw UEE.
(2) It should be default replacement byte array not replace string for all
getBytes()
Hi all,
Thanks for taking the time to look at this - most appreciated. I've pushed
the latest iteration to http://cr.openjdk.java.net/~
rwarburton/string-patch-webrev-8/ http://cr.openjdk.java.net/%
7Erwarburton/string-patch-webrev-8/.
I think this is looking good.
Thanks - I've pushed a
On 11/15/2014 07:07 PM, Richard Warburton wrote:
Hi all,
[...]
A good observation. I've added variants which take a String for the charset
name as well the charset variants.
Having said that - wouldn't it also be a good idea to replicate the caching
on the charset versions as well as the
Hi,
Having said that - wouldn't it also be a good idea to replicate the caching
on the charset versions as well as the charset name? I don't see any
obvious reason why this isn't possible but perhaps there's something I'm
missing here. Probably cleaner as a separate patch either way.
On 26/10/2014 21:10, Richard Warburton wrote:
:
Thanks for taking the time to look at this - most appreciated. I've
pushed the latest iteration to
http://cr.openjdk.java.net/~rwarburton/string-patch-webrev-8/
http://cr.openjdk.java.net/%7Erwarburton/string-patch-webrev-8/.
I think this is
On 10/28/2014 03:52 PM, Alan Bateman wrote:
On 26/10/2014 21:10, Richard Warburton wrote:
:
Thanks for taking the time to look at this - most appreciated. I've
pushed the latest iteration to
http://cr.openjdk.java.net/~rwarburton/string-patch-webrev-8/
On 10/26/2014 02:10 PM, Richard Warburton wrote:
The getBytes(ByteBuffer, Charset) method needs a bit more javadoc. You
should be able to borrow from text from the CharsetEncoder#encode methods
to help with that.
I've updated the Javadoc with more information about the encoding and made
Hi Alan,
I think this looks better but I have a few comments on the API.
Thanks for taking the time to look at this - most appreciated. I've pushed
the latest iteration to
http://cr.openjdk.java.net/~rwarburton/string-patch-webrev-8/.
For String(ByteBuffer, Charset) then it's still
On 19/10/2014 23:13, Richard Warburton wrote:
Hi,
Hi Richard, couple comments after a quick scan.
Thanks for your comments - only just had a post Javaone chance to look at
this stuff. I've pushed an update to:
*http://cr.openjdk.java.net/~rwarburton/string-patch-webrev-7
Hi,
Hi Richard, couple comments after a quick scan.
Thanks for your comments - only just had a post Javaone chance to look at
this stuff. I've pushed an update to:
*http://cr.openjdk.java.net/~rwarburton/string-patch-webrev-7
http://cr.openjdk.java.net/~rwarburton/string-patch-webrev-7*
(1)
Hi,
On 09/22/2014 01:25 PM, Richard Warburton wrote:
Hi all,
A long-standing issue with Strings in Java is the ease and performance of
creating a String from a ByteBuffer. People who are using nio to bring in
data off the network will be receiving that data in the form of bytebuffers
and
Hi Alan,
Thanks for the feedback.
The direction seems reasonable but I wonder about the offset/length (and
destOffet) parameters as this isn't consistent with how ByteBuffers were
originally intended to be used. That is, when you read the bytes from the
wire into a ByteBuffer and flip it then
Hi Richard, couple comments after a quick scan.
(1) #474, the IOBE probably is no longer needed in case of ByteBuffer.
parameter.
(2) for methods that have the ByteBuffer as input, it would be desirable
to specify clearly that
the bytes are read from position to limit, and whether or
On 9/25/14 9:24 AM, Xueming Shen wrote:
Hi Richard, couple comments after a quick scan.
(1) #474, the IOBE probably is no longer needed in case of
ByteBuffer. parameter.
(2) for methods that have the ByteBuffer as input, it would be
desirable to specify clearly that
the bytes are read
Hi all,
A long-standing issue with Strings in Java is the ease and performance of
creating a String from a ByteBuffer. People who are using nio to bring in
data off the network will be receiving that data in the form of bytebuffers
and converting it to some form of String. For example restful
On 22/09/2014 12:25, Richard Warburton wrote:
:
I've put together a patch that implements this to demonstrate the overall
direction.
http://cr.openjdk.java.net/~rwarburton/string-patch-webrev-5/
I'm happy to take any feedback on direction or the patch itself or the
overall idea/approach. I
Compare with https://bugs.openjdk.java.net/browse/JDK-6695386
Maybe that would help a little.
-Ulf
Am 22.09.2014 um 13:25 schrieb Richard Warburton:
Hi all,
A long-standing issue with Strings in Java is the ease and performance of
creating a String from a ByteBuffer. People who are using nio
27 matches
Mail list logo
