Add getChars to CharSequence

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

Another preliminary webrev is out at

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

> On Thu, Apr 11, 2013 at 12:55 PM, Ulf Zibis <Ulf.Zibis at> 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