RFR: 8012665: CharSequence.chars, CharSequence.codePoints (original) (raw)
Alan Bateman Alan.Bateman at oracle.com
Fri May 24 13:39:03 UTC 2013
- Previous message: RFR: 8012665: CharSequence.chars, CharSequence.codePoints
- Next message: RFR: 8014854 (was Re: RFR: 8012665: CharSequence.chars, CharSequence.codePoints)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 29/04/2013 17:51, Henry Jen wrote:
On 04/26/2013 06:21 AM, Alan Bateman wrote:
: I looked through the webrev and it looks okay as a first version. I agree with Martin's suggestion on the performance. I also wonder if CharBuffer will need to override at least chars(). This could of course be done as a follow-on piece of work.
I agree, let's follow up on this after first version. Just to follow-up on this thread from a few weeks ago.
I did a few tests with CharBuffer.chars() and the default implementation performs very poorly as expected. This is easily fixed by adding a spliterator with direct access to the buffer contents and that is straight-forward to do:
http://cr.openjdk.java.net/~alanb/8014854/webrev/
I've changed the templates used to generated the buffer classes so that ints/longs/doubles() could be added to Int/Long/DoubleBuffer if needed (which might be interesting when the buffers are backed by memory outside of the heap).
The yak shaving in CompileJavaClasses.gmk is because the changes to the generated CharBuffer exposes a bug in the build of JObjC.jar on Mac.
-Alan.
- Previous message: RFR: 8012665: CharSequence.chars, CharSequence.codePoints
- Next message: RFR: 8014854 (was Re: RFR: 8012665: CharSequence.chars, CharSequence.codePoints)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]