Add getChars to CharSequence

Martin Buchholz martinrb at google.com
Mon Apr 22 19:45:40 UTC 2013


Another preliminary webrev is out at
http://cr.openjdk.java.net/~martin/webrevs/openjdk8/getChars/

Alan et al: Before continuing, can we:

Have thumbs up on the changes to out of bounds exceptions?

The handling of the rw conditional in the preprocessed sources is very
confusing and error-prone.  I cleaned up some of that code and added tests
to catch the most obvious mistakes.  We can do this all in a single
changeset, but if you like, we can separate the general nio buffer
improvements into a separate changeset; if so, file a bug.

Direct-X-Buffer.java.template
There's a minor comedy of errors here:

     public $Type$Buffer get($type$[] dst, int offset, int length) {-#if[rw]

...

-#else[rw]-        throw new ReadOnlyBufferException();-#end[rw]

get should never throw ReadOnlyBufferException, but in fact it never does,
since the entire method is within a #if[rw] block, causing the throw to be
dead code.




On Thu, Apr 11, 2013 at 2:12 PM, Martin Buchholz <martinrb at google.com>wrote:

>
>
>
> On Thu, Apr 11, 2013 at 12:55 PM, Ulf Zibis <Ulf.Zibis at cosoco.de> wrote:
>
>>
>> Anyway as those methods all need some CPU time to execute normally, I'm
>> not sure if it's worth to save 1 comparison by outsourcing.
>>
>
> Saving one comparison is worth doing in any case in these
> performance-critical methods.
> "Out-lining" the creation of the detail message is a standard refactoring
> that is known to make hotspot happy.
>
>
>> Additionally having getCharsOutOfBounds as source for the exceptions
>> cause/stacktrace could lead to some confusion.
>>
>
> Let's use this sane exception detail:
>
>     private String outOfBoundsMsg(int srcBegin, int srcEnd) {
>         return "srcBegin = " + srcBegin
>             + ", srcEnd = " + srcEnd
>             + ", length() = " + count;
>     }
>
>



More information about the core-libs-dev mailing list